[PATCH] .gitignore: Ignore cscope and other *tags files
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@redhat.com> --- .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 -- 2.39.1
On a Thursday in 2023, 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@redhat.com> --- .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
Should we ignore GRRRTAGS too?
+/GTAGS +/TAGS +/cscope.files +/cscope.in.out +/cscope.out +/cscope.po.out +/tags
# clangd related ignores .clangd
Reviewed-by: Ján Tomko <jtomko@redhat.com> Jano
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@redhat.com>
Reviewed-by-with-prejudice: Laine Stump <laine@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).
--- .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
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@redhat.com>
Reviewed-by-with-prejudice: Laine Stump <laine@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. 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
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@redhat.com>
Reviewed-by-with-prejudice: Laine Stump <laine@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
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@redhat.com>
Reviewed-by-with-prejudice: Laine Stump <laine@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
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 :-))
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@redhat.com>
Reviewed-by-with-prejudice: Laine Stump <laine@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
participants (5)
-
Erik Skultety -
Ján Tomko -
Laine Stump -
Laine Stump -
Martin Kletzander