[PATCH] .gitignore: Ignore cscope and other *tags files

[Martin Kletzander]

On Fri, Feb 03, 2023 at 08:49:06AM +0100, Erik Skultety wrote:
>On Thu, Feb 02, 2023 at 02:02:13PM -0500, Laine Stump wrote:
>> On 2/2/23 10:37 AM, Martin Kletzander wrote:
>> > Commit f7114e61dbc2 cleaned up way too much and now that I have cscope
>> > working again I noticed there are some files that ought to stay ignored.
>> >
>> > Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>>
>> Reviewed-by-with-prejudice: Laine Stump <laine at redhat.com>
>>
>> I had sent a patch a year or two ago (maybe longer?) to re-add the cscope
>> files to the ignore, but someone expressed reluctance (because I should be
>> putting that in a global ignore or something, I forget), so rather than
>> ruffle feathers I just dropped the patch and spent the last two years being
>> mildly ignored each time I ran git status (I overcame the threshold of sloth
>> one time to get rid of it, but couldn't manage the tiny amount of ambition
>> for a 2nd).
>
>Yes. Unfortunately, the patch has been pushed already. Although cscope might be
>common among libvirt devs, it isn't something related to the project. The point
>is, whatever artifact that doesn't come directly from a libvirt build,
>automation or other helper scripts we maintain in the repo should NOT be put
>into the project's gitignore and instead should go to one's global .gitignore
>in their home.
>

Oh, cool, I can do that?  I have to read up on that.  I did not even
think of it, especially when we already had "tags" there.  And the
commit message removing it did not mention the reasoning behind it.
I'll send a new patch reverting this one *and* explain how to use a
local/user/global ignore or whatever we want to call it.

>Here's another example which better explains it in Python. There are so many
>IDEs that are commonly used nowadays by developers? Is an IDE forced by the
>project? Most likely not. Wether it's PyCharm, Eclipse, Qt or whatever it is
>people consider the best environment since the invention of sliced bread, all
>of these create  a bunch of app specific hidden files that maintaining such a
>.gitignore becomes unpleasant quickly. The outcome then is that there is a
>Github repo (too lazy to search for it) providing gitignore templates for new
>projects which already contain most of these artifacts. So, even though this is
>pure bike shedding, there is really isn't a compelling reason to have anything
>strictly unrelated to the project in the repo's gitignore file. Now, the story
>would normally be the same for ctags, but we already do maintain '.ctags' as
>part of the repo - was it the right decision to have included in the first
>place? Probably not, but removing it now is pointless, but at the same time IMO
>using it as a precedent to add more project-unrelated artifact ignores is also
>not correct.
>
>My 2c.
>
>Regards,
>Erik
>
>>
>> > ---
>> >   .gitignore | 12 +++++++++++-
>> >   1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/.gitignore b/.gitignore
>> > index 469539134280..61ea7779b02b 100644
>> > --- a/.gitignore
>> > +++ b/.gitignore
>> > @@ -19,7 +19,17 @@ __pycache__/
>> >   # libvirt related ignores
>> >   /build/
>> >   /ci/scratch/
>> > -tags
>> > +
>> > +# *tags and cscope files
>> > +/GPATH
>> > +/GRTAGS
>> > +/GTAGS
>> > +/TAGS
>> > +/cscope.files
>> > +/cscope.in.out
>> > +/cscope.out
>> > +/cscope.po.out
>> > +/tags
>> >   # clangd related ignores
>> >   .clangd
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20230203/151f2a1e/attachment.sig>