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