Re: [PATCH] virsh: Provide completer for virtualization types
On Fri, Apr 01, 2022 at 09:24:01AM +0200, Michal Prívozník wrote:
On 4/1/22 09:02, Erik Skultety wrote:
> On Tue, Mar 29, 2022 at 08:40:29AM +0200, Michal Prívozník wrote:
>> On 3/25/22 23:51, natto1784 wrote:
>>> Related: https://gitlab.com/libvirt/libvirt/-/issues/9
>>> Signed-off-by: natto1784 <natto(a)weirdnatto.in>
>>> ---
>>> .gitignore | 4 ++++
>>> tools/virsh-completer-host.c | 12 ++++++++++++
>>> tools/virsh-completer-host.h | 5 +++++
>>> tools/virsh-host.c | 3 +++
>>> 4 files changed, 24 insertions(+)
>>>
>>> diff --git a/.gitignore b/.gitignore
>>> index 4695391..62012f4 100644
>>> --- a/.gitignore
>>> +++ b/.gitignore
>>> @@ -23,4 +23,8 @@ tags
>>>
>>> # clangd related ignores
>>> .clangd
>>> +.cache/clangd
>>> compile_commands.json
>>> +
>>> +# ccls cache
>>> +.ccls-cache
>
> Neither of ^these are actually related in any way to the project itself or the
> toolchain adopted by the project, on the contrary both relate to user's
> working environment. Therefore these should not be placed in the project's
> gitignore and instead be put in your own (global) one.
> I didn't even know we had clangd bits in there which should have never been the
> case IMO (I spotted this patch by an accident).
> A bit of background: I was told the same thing in the virt-manager project and
> ever since I'm using my own gitignore for everything that does not strictly
> relate the toolchain used by the project.
I don't disagree, but we already have records for
vim/emacs/clang/python(?). I believe the same argument can be made about
those files too.
I admit I wasn't very clear in what I wrote, so correcting it now - yes, you
are right, I noticed it along with the clangd bits and I never noticed them
until now as I never really had a need to keep an eye on the file using my
local gitignores :). However, that doesn't mean it should become a precedent.
If anything we should remove those too, but at the same time I don't feel a
strong justification for such a change, so instead we should politely refuse
any further changes like this one (strictly non-related to the project) to the
gitignore from now on.
BTW: why do we have __pycache__/ in there? Isn't that a relic from the
old times, when python bindings were living in the same repo?
Probably, but the same applies...
Erik