Re: Overly aggressive .gitignore file?

[Masahiro Yamada]

Hello Linus,

On Wed, Jul 5, 2023 at 4:49 AM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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.


Exactly. You are right.

My motivation for 534066a983df was
the silly scripts/list-gitignored tool.

I needed to exclude as many untracked files as possible
from source packages.

That tool is gone with 05e96e96a315.
I have no objection in reverting 534066a983df.


If somebody wants to ignore *.mbx for some reason,
they can add the *.mbx pattern to
~/.config/git/ignore.



Perhaps, a slightly similar case is *.patch.
(We do ignore *.patch)

People quite often run 'git format-patch'.
And, the generated patches have similar prefixes.
(0001-, 0002-, 0003-, ..., for good reasons)

The autocomplete does not work if 000* files
exist from the previous time I ran 'git format-patch'.
I repeatedly run 'rm -f 00*' even if 'git status' does not show them.



A tricky case is *.orig and *.rej
We ignore *.orig.
We do not ignore *.rej (but we used to ignore it)
The reason is described in:
1f5d3a6b6532e25a5cdf1f311956b2b03d343a48



So, actually I cannot tell the clear criteria.
(perhaps, whether Linus is annoyed or not?)

I have no objection in either way.




If we want to minimize our ignore patterns, we could drop
*.mbx, *.cover, *.patch, *~, \#*#, *.orig, patches, series, etc.
from our .gitignore because they are not project-specific.

If people want to ignore them, they can add them
to ~/.config/git/ignore.







-- 
Best Regards
Masahiro Yamada