[PATCH] virsh: Provide completer for virtualization types

[Erik Skultety]

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 at 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