Message-ID: <20230704215600.GA22271@1wt.eu>
Date:   Tue, 4 Jul 2023 23:56:00 +0200
From:   Willy Tarreau <w@....eu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Nicolas Schier <nicolas@...sle.eu>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Overly aggressive .gitignore file?

On Tue, Jul 04, 2023 at 02:44:47PM -0700, Linus Torvalds wrote:
> On Tue, 4 Jul 2023 at 14:34, Willy Tarreau <w@....eu> 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

Powered by blists - more mailing lists