Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHk-=wiJHMje8cpiTajqrLrM23wZK0SWetuK1Bd67c0OGM_BzQ@mail.gmail.com>
 <ZKTncHqLwgbZbRVl@bergen.fjasle.eu>
In-Reply-To: <ZKTncHqLwgbZbRVl@bergen.fjasle.eu>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Wed, 5 Jul 2023 14:04:05 +0900
Message-ID: <CAK7LNARM04vuv7o+GJ082140efWCCN-q7jCaacrA_DT=FuoUWQ@mail.gmail.com>
Subject: Re: Overly aggressive .gitignore file?
To:     Nicolas Schier <nicolas@fjasle.eu>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Jul 5, 2023 at 12:46=E2=80=AFPM Nicolas Schier <nicolas@fjasle.eu> =
wrote:
>
> 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.


Already reverted.
(d528014517f2b0531862c02865b9d4c908019dc4)

I also chimed-in too late.

If he wants to hear opinions from people
who live in different time zones, he can wait
for 24 hours, but his decision is usually quick.


--=20
Best Regards
Masahiro Yamada