On Wed, Jul 5, 2023 at 12:46 PM Nicolas Schier <nicolas@xxxxxxxxx> 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.
--
Best Regards
Masahiro Yamada
