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

[Martin Kletzander]

On Fri, Feb 03, 2023 at 06:13:23PM -0500, Laine Stump wrote:
>On 2/3/23 2:49 AM, 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
>
>s/ignored/annoyed/
>
>(I wouldn't really care if I was ignored - that's somebody else's
>problem :-)
>
>>> 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.
>
>Okay, now you've forced me to go look it up....
>
>And, it turns out that just creating a ~/.gitignore isn't sufficient;
>you must also tell git where your global .gitignore file is located, with:
>
>   git config --global core.excludesfile ~/.gitignore
>
>If only I'd had the ambition to spend that 30 seconds sometime in the
>last 2 years :-P
>

git config man page says it all:

core.excludesFile:
   Specifies the pathname to the file that contains patterns to describe
   paths that are not meant to be tracked, in addition to .gitignore
   (per-directory) and .git/info/exclude. Defaults to
   $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or
   empty, $HOME/.config/git/ignore is used instead.  See gitignore(5).

so even easier if your git config is migrated to ~/.git/config/, I only
knew about the per-project settings.

And that answers my question why, upon reverting the commit, I had not
seen some of the files in git status.  Because I already had some of
them there.  I had no idea I already did the setup. <facepalm/>

>>
>> 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.
>
>And yet we have lines in our .gitignore for "emacs-related" and
>"vim-related" ignores (the latter was *added* in the same commit that
>removed the cscope files :-P).
>
>> 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.
>
>I see your point, but the precedent was already set - byproduct files of
>the developers' environment can be included in .gitignore; anything
>beyond that is just a matter of degree and opinion (and, as I said, any
>removal has been inconsistent - the same patch removed cscope files, but
>added vim files).
>
>Another point to consider is that having "common" excluded files in the
>project .gitignore will lead to less user error among novice
>contributors who don't know about the global .gitignore, and just run
>"git add" to add *everything* to their commit. Then we need to either
>waste time with back-and-forth in email telling them to resubmit without
>the extra files, or else go to the trouble of locally removing those
>files from the patch before pushing it. How many times has that
>happened? None that I recall. How many times might it have happened if
>the "emacs related" and "vim related" sections weren't in the project
>.gitignore? No idea, very possibly 0. But it's a nice bikeshed argument
>for the end of a Friday afternoon.
>
>(Anyway, now that I've been forced to spend the 30 seconds, I am no
>longer saddened by the idea of removing the cscope files from
>.gitignore, although it does seem like a wasted of effort once they're
>already in. Almost nearly 1/10th as much effort as I've wasted on this
>reply :-))
>

Good that we have Fridays then =D
-------------- 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/20230206/18519484/attachment.sig>