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@xxxxxxxxxxxxx> > >>> --- > >>> .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
