On Tue, Jul 04, 2023 at 02:44:47PM -0700, Linus Torvalds wrote: > 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. I did again and again. You said: 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., So for me what this means is that when you press <tab>, nothing happens. When I do press tab, in the exact same situation, I'm presented with the list of matching files. > 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. Then maybe we don't have the same definition for "auto-completion". For me auto-completion presents me with a list of matches that I can pick from, and when it doesn't work, I press <tab> and am presented with nothing, typically something which happens when programmable completion is involve and doesn't find any match. > 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 This point I perfectly understand, but there's also this "ls" command that lists file names starting with 2023-* if required. I mean, there's even nothing that requires that the mbox files are whithin the git repo itself, they could very well come from /tmp and you wouldn't use git status there. The value I'm seeing in what you're looking for is to quickly detect that there remain these old turds in the directory (and possibly remove them all at once). But that should not be relevant to the auto-completion if we have the same definition of it. > 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. I did, for the 3rd time. I understood that you have a collection of old ".mbx" files in your directory and that when you start typing "git am 2023-<tab>" it proposes nothing, and that you say it's due to the .gitignore that ignores .mbx files. And I maintain that if it's the case the .gitignore should not be related to *this*, but only to the fact that they're not listed to you in "git status". Willy