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
Attachment:
signature.asc
Description: PGP signature
