Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 4 Jul 2023 20:41:29 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Willy Tarreau <w@1wt.eu>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nicolas Schier <nicolas@fjasle.eu>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Overly aggressive .gitignore file?
Message-ID: <20230705004129.GI1178919@mit.edu>
References: <CAHk-=wiJHMje8cpiTajqrLrM23wZK0SWetuK1Bd67c0OGM_BzQ@mail.gmail.com>
 <20230704211509.GA21834@1wt.eu>
 <CAHk-=wjH4O6v_EwVB=t_6Haky2jOiejHbCkCTvgNQWo1ghy8-w@mail.gmail.com>
 <20230704213415.GA21872@1wt.eu>
 <CAHk-=wjPEjrB7eCukREhWu-0qfjbFD-K8sk1TYYRgeHzYr1tuQ@mail.gmail.com>
 <20230704215600.GA22271@1wt.eu>
 <CAHk-=whMytacPBHfKKi8GYdgfadNy5LA-1TDHrTtz22eJr2B1Q@mail.gmail.com>
 <20230704222758.GB22271@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230704222758.GB22271@1wt.eu>
Precedence: bulk

For whatever it's worth, I always run "b4 am -o /tmp/m ...", so all of
the .mbox files end up in /tmp/m.  Similarly, I'll always run "git ty
-o /tmp/e ..." so all of the thanks file end up in /tmp/e.  And that
way I inspect the b4 output files before I run "git am -s /tmp/m/..."
or "git send-mail /tmp/e/...".

So I never end up with the problem of stale b4 turds in the kernel
tree.  My one wish is that b4 would automatically create the arguments
to the -o otpion if they don't exist, so I'm not having to type "rm -r
/tmp/m ; mkdir /tmp/m" before I run b4, but as far as I'm concerned,
it's much better than having the turds in my kernel tree.

The other thing I got a bit confused about is the "autocomplete not
working".  At least for me, if there are two files that have the same
prefix, say, 2023, when type "2023<TAB>", the terminal bell goes
"fweep", which makes me understand that the prefix was not ambiguous,
and then the second time when I hit <TAB> I'll see the possible
autocomplete options, so I know what unique characters I might need to
type in order for autocomplete to make forward progress.  Now, it
might be that you've turned off the terminal bell, so you don't get
the hint about why autocomplete didn't fully complete the filename, so
it appears as it was "autocomplete not working", as opposed to your
not getting the feedback about why it didn't do more autocompletion.

> Sure but apparently the point of that commit was precisely to avoid
> *risking* to commit them for other users, or maybe just not seeing
> too many of them when running git status to make sure the rest that
> they consider more important is actually committed.

Well, if you use directories in /tmp for the b4 output, there's no
risk of them accidentally getting committed into the tree.  And unless
you do something like "git add .", there's no chance they would
accidentally get committed anyway, so I'm not sure I see the point.
I'm always manually using "git add <filename>" precisely because I
don't *trust* "git add ." not accidentally including stuff I don't
want....

						- Ted