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(a)redhat.com>
>
> Reviewed-by-with-prejudice: Laine Stump <laine(a)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
>