Re: Overly aggressive .gitignore file?

[Linus Torvalds]

On Tue, 4 Jul 2023 at 14:34, Willy Tarreau <w@xxxxxx> wrote:
>
> But the git am completion rules should actually *not* rely on
> git status output. At least in my opinion.

Christ, Willy.

Where did I talk about git am completion rules?

b4 am DOES THE RIGHT THING.

Completion DOES THE RIGHT THING.

THOSE STUPID HISTORICAL TURDS IS THE PROBLEM.

And the reason those turds exist? Because I don't notice, BECAUSE GIT
STATUS DOESN'T TELL ME!

> Here I pressed [Tab] after "2023" and it automatically completed.

Go back and READ THE EMAIL ALREADY.

Let me quote the relevant part again:

** 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 go and create an OLD STALE TURD that *ALSO* has that 2023-xyz name,
and now try again.

Notice how auto-completion doesn't work, because there are now
*multiple* files beginning with the same filename.

Auto-completion isn't smart enough to know "oh, he already committed
that old mbox file and I should ignore it".

And _I_ didn't notice until auto-complete failed, because our
".gitignore" file told all the infrastructure to - wait for it -
ignore that file.

So "git status" at no point gave me that helpful

   Untracked files:
     (use "git add <file>..." to include in what will be committed)
   2023xyzzy.mbx

output to let me know that "Oh, btw, you have that old turd in your tree".

Please. Read the email.

              Linus