Message-ID: <ZKTncHqLwgbZbRVl@bergen.fjasle.eu>
Date:   Wed, 5 Jul 2023 05:45:52 +0200
From:   Nicolas Schier <nicolas@...sle.eu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Overly aggressive .gitignore file?

On Tue 04 Jul 2023 12:49:01 GMT, Linus Torvalds wrote:
> So this keeps happening to me - I go to apply a patch I just
> downloaded with 'b4', and I do my regular
> 
>      git am -s --whitespace 2023<tab>
> 
> and the dang thing doesn't autocomplete.,
> 
> The reason it doesn't auto-complete ends up being that my kernel tree
> contains some other random stale mbx file from the _previous_ time I
> did that, because they effectively get hidden from "git status" etc by
> our .gitignore file.
> 
> So then those stale files end up staying around much too long and not
> showing up on my radar even though they are just old garbage by the
> time I have actually applied them.
> 
> And I always use auto-complete, because those filenames that 'b4'
> generate are ridiculously long (for good reason).
> 
> And the auto-complete always fails, because b4 just uses a common
> prefix pattern too (again, for a perfectly good reason - I'm not
> complaining about b4 here).
> 
> This has been a slight annoyance for a while, but the last time it
> happened just a moment ago when I applied David Howells' afs patch
> (commit 03275585cabd: "afs: Fix accidental truncation when storing
> data" - not that the particular commit matters, I'm just pointing out
> how it just happened _again_).
> 
> So I'm really inclined to just revert the commit that added this
> pattern: 534066a983df (".gitignore: ignore *.cover and *.mbx"). It's
> actively detrimental to my workflow.
> 
> I'm not sure why that pattern was added, though. These are not
> auto-generated files from our build.  So before I go off and revert
> it, let's ask the people mentioned in that commit.
> 
> I *suspect* the thing that triggered this wasn't that people actually
> wanted to ignore these files, but that it was related to the misguided
> "let's use .gitignore to build source packages" project.
> 
> But at least for me, it's a real problem when .gitignore contains
> other files than the ones we actually generate.
> 
> The only one that actually commonly affects me is the *.mbx file,
> although I could certainly see the same being true of the *.cover
> thing.
> 
> And there might certainly be other patterns like this that I just
> don't react to, because they don't have the same detrimental effects
> on how I work.
> 
> Comments?
> 
>                Linus

Thanks for sharing some details of your concrete workflow.  I think, 
having this in mind, it is quite a fair point to criticise the handling 
(or ignoring, respectively) of files that are are not generated or used 
during kernel builds.  But in general, I don't find it that easy to 
draw the line; should we also remove

   *.kdev4
   *.orig
   *.patch
   *~
   \#*#
   patches
   series

from .gitignore?   I don't think so, even though they (partially) fall 
into the same category.

From my point of view, this is a decision of personal preference.
I do like the ignoring of *.mbx and *.cover, as I tend to have those 
files around for some time by intention.  But a revert would not cause 
any trouble to me and optimisation of your workflow is magnitudes more 
important, so I am perfectly fine with it, if you want to have the 
commit reverted.

Kind regards,
Nicolas

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists