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.
But at least for me, it's a real problem when .gitignore contains
other files than the ones we actually generate.
The only one that actually commonly affects me is the *.mbx file,
although I could certainly see the same being true of the *.cover
thing.
And there might certainly be other patterns like this that I just
don't react to, because they don't have the same detrimental effects
on how I work.
Comments?
Linus
On Tue, 4 Jul 2023 at 14:15, Willy Tarreau <[email protected]> wrote:
>
> I don't understand why your completion on "git am" should rely on
> *tracked* files.
It doesn't.
Read that email again.
It fails on *untracked* files that are hidden from "git status" and
friends by our .gitignore pattern:
*.mbx
added by commit 534066a983df (".gitignore: ignore *.cover and *.mbx")
So when I have those old stale mbx files around, I don't see them,
because "git status" will happily say
nothing to commit, working tree clean
with no mention of those old turds.
Really. Try it.
> From a workflow perspective that makes no sense,
> as by definition, git am will consume only *untracked* files.
I don't think you actually read my email.
Linus
On Tue, Jul 04, 2023 at 02:20:36PM -0700, Linus Torvalds wrote:
> On Tue, 4 Jul 2023 at 14:15, Willy Tarreau <[email protected]> wrote:
> >
> > I don't understand why your completion on "git am" should rely on
> > *tracked* files.
>
> It doesn't.
>
> Read that email again.
>
> It fails on *untracked* files that are hidden from "git status" and
> friends by our .gitignore pattern:
>
> *.mbx
>
> added by commit 534066a983df (".gitignore: ignore *.cover and *.mbx")
>
> So when I have those old stale mbx files around, I don't see them,
> because "git status" will happily say
>
> nothing to commit, working tree clean
>
> with no mention of those old turds.
But the git am completion rules should actually *not* rely on
git status output. At least in my opinion.
> Really. Try it.
I did and for me on this machine I don't have the problem:
willy@pcw:~/linux$ git status
On branch 20230702-nolibc-series1+2_2
Your branch is up to date with 'origin/20230702-nolibc-series1+2_2'.
nothing to commit, working tree clean
willy@pcw:~/linux$ echo blah > 2023-new-patch.mbx
willy@pcw:~/linux$ git status
On branch 20230702-nolibc-series1+2_2
Your branch is up to date with 'origin/20230702-nolibc-series1+2_2'.
=> .mbx is indeed ignored
nothing to commit, working tree clean
willy@pcw:~/linux$ git am -s --whitespace 2023-new-patch.mbx
^C
Here I pressed [Tab] after "2023" and it automatically completed.
By git completion is certainly quite old, as I really don't change
it often once I have a satisfying one. My git-completion.bash script
has this in case that helps:
_git_am ()
{
__git_find_repo_path
if [ -d "$__git_repo_path"/rebase-apply ]; then
__gitcomp "$__git_am_inprogress_options"
return
fi
case "$cur" in
--whitespace=*)
__gitcomp "$__git_whitespacelist" "" "${cur##--whitespace=}"
return
;;
--*)
__gitcomp_builtin am "--no-utf8" \
"$__git_am_inprogress_options"
return
esac
}
> > From a workflow perspective that makes no sense,
> > as by definition, git am will consume only *untracked* files.
>
> I don't think you actually read my email.
Yes I did and I neither experience your problem nor figure why it
should happen, because I don't see the relation between gitignore
and anything that git am should be allowed to consume :-/
Willy
On Tue, 4 Jul 2023 at 14:34, Willy Tarreau <[email protected]> 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
On Tue, Jul 04, 2023 at 02:44:47PM -0700, Linus Torvalds wrote:
> On Tue, 4 Jul 2023 at 14:34, Willy Tarreau <[email protected]> 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
On Tue, 4 Jul 2023 at 14:56, Willy Tarreau <[email protected]> wrote:
>
> This point I perfectly understand, but there's also this "ls" command
> that lists file names starting with 2023-* if required.
You know what? I'm done arguing with you.
Sure. I could also do "echo * | grep 2023" or something.
Or I could just remember every single mbx file I ever used.
Or maybe I could remember to just delete them immediately after using.
Or I could do any number of other things.
But what do you think "git status" is supposed to do?
Here's a theory - it's supposed to tell me about the status of my git tree.
Maybe it's supposed to tell me about extra files that maybe I should
be aware of. Maybe I should delete them. Maybe I should commit them.
Who knows?
Or maybe it's supposed to tell me that I've forgotten to push, or that
I have diffs I haven't committed.
All those things that are specific to having a git tree, that tools
like 'ls' simply don't know to do.
It's a crazy theory, I know. But just go with it, ok.
And *if* we pretend for a moment that this is what "git status" is
supposed to do, then maybe it should have reminded me about stale
random files in that directory that ACTIVELY BREAK MY WORKFLOW.
Maybe that isn't your workflow.
Maybe you're perfectly fine not getting a unique auto-complete,
because you *want* your git directory filled with irrelevant crap.
Or maybe you just always do "ls" religiously and look for random files
in general, because you are bored and it fills up that dead time.
But how about you just accept the fact that for some of us, the whole
point of 'git status" is to tell about these kinds of things, ok?
I'm now done. I have reverted that commit in my tree and pushed it
out, because while I was interested in hearing about any possible
other use for that overly aggressive gitignore entry, I'm not in the
least interested in you trying to teach me about esoteric tools like
'ls', or telling me that "unsuccessful auto-complete is still an
auto-complete".
Linus
On Tue, Jul 04, 2023 at 03:14:11PM -0700, Linus Torvalds wrote:
> But what do you think "git status" is supposed to do?
>
> Here's a theory - it's supposed to tell me about the status of my git tree.
I agree with this and use it for the same purpose.
> Maybe it's supposed to tell me about extra files that maybe I should
> be aware of. Maybe I should delete them. Maybe I should commit them.
> Who knows?
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.
> And *if* we pretend for a moment that this is what "git status" is
> supposed to do, then maybe it should have reminded me about stale
> random files in that directory that ACTIVELY BREAK MY WORKFLOW.
I agree with this.
> Maybe that isn't your workflow.
>
> Maybe you're perfectly fine not getting a unique auto-complete,
> because you *want* your git directory filled with irrelevant crap.
It's not a matter of being fine or not fine, it's the way your question
was posed. I'm sorry, but I'm seeing so many times completion do nothing
on some distros when passing certain args to various everyday commands
(to the point that I learned to type "complete -r" to kill stupid rules),
that *my* understanding of "doesn't autocomplete" means exactly that. If
you say "it proposes me the whole list of old turds" I perfectly
understand how annoying that can be, exactly like when I leave plenty of
git-format-patch files and I want to git-am another one and can't spot
it. It's just that *for me* it's not the problem that was presented,
hence my suggestions about completion rules being faulty.
I understand that you might be angry due to a commit that broke your
workflow and that pisses you off, and that maybe your initial message
was written in a hurry to flush your anger, but please also accept
that not everyone possibly understood it the way you hoped it would
be, because it *was* ambiguous.
Anyway, you fixed it so now the problem is solved.
Willy
On Tue, Jul 04, 2023 at 12:49:01PM -0700, Linus Torvalds 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 don't understand why your completion on "git am" should rely on
*tracked* files. From a workflow perspective that makes no sense,
as by definition, git am will consume only *untracked* files. Are
you sure there isn't something wrong elsewhere in your completion
rules, that would make your "git am" complete only with tracked
files ? Most likely it should use a rule very similar to what
"git add" uses.
Just my two cents,
Willy
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
Hello Linus,
On Wed, Jul 5, 2023 at 4:49 AM Linus Torvalds
<[email protected]> 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
On Tue 04 Jul 2023 12:49:01 GMT, Linus Torvalds 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.
>
> But at least for me, it's a real problem when .gitignore contains
> other files than the ones we actually generate.
>
> The only one that actually commonly affects me is the *.mbx file,
> although I could certainly see the same being true of the *.cover
> thing.
>
> And there might certainly be other patterns like this that I just
> don't react to, because they don't have the same detrimental effects
> on how I work.
>
> Comments?
>
> Linus
Thanks for sharing some details of your concrete workflow. I think,
having this in mind, it is quite a fair point to criticise the handling
(or ignoring, respectively) of files that are are not generated or used
during kernel builds. But in general, I don't find it that easy to
draw the line; should we also remove
*.kdev4
*.orig
*.patch
*~
\#*#
patches
series
from .gitignore? I don't think so, even though they (partially) fall
into the same category.
From my point of view, this is a decision of personal preference.
I do like the ignoring of *.mbx and *.cover, as I tend to have those
files around for some time by intention. But a revert would not cause
any trouble to me and optimisation of your workflow is magnitudes more
important, so I am perfectly fine with it, if you want to have the
commit reverted.
Kind regards,
Nicolas
On Wed, Jul 5, 2023 at 12:46 PM Nicolas Schier <[email protected]> wrote:
>
> On Tue 04 Jul 2023 12:49:01 GMT, Linus Torvalds 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.
> >
> > But at least for me, it's a real problem when .gitignore contains
> > other files than the ones we actually generate.
> >
> > The only one that actually commonly affects me is the *.mbx file,
> > although I could certainly see the same being true of the *.cover
> > thing.
> >
> > And there might certainly be other patterns like this that I just
> > don't react to, because they don't have the same detrimental effects
> > on how I work.
> >
> > Comments?
> >
> > Linus
>
> Thanks for sharing some details of your concrete workflow. I think,
> having this in mind, it is quite a fair point to criticise the handling
> (or ignoring, respectively) of files that are are not generated or used
> during kernel builds. But in general, I don't find it that easy to
> draw the line; should we also remove
>
> *.kdev4
> *.orig
> *.patch
> *~
> \#*#
> patches
> series
>
> from .gitignore? I don't think so, even though they (partially) fall
> into the same category.
>
> From my point of view, this is a decision of personal preference.
> I do like the ignoring of *.mbx and *.cover, as I tend to have those
> files around for some time by intention. But a revert would not cause
> any trouble to me and optimisation of your workflow is magnitudes more
> important, so I am perfectly fine with it, if you want to have the
> commit reverted.
Already reverted.
(d528014517f2b0531862c02865b9d4c908019dc4)
I also chimed-in too late.
If he wants to hear opinions from people
who live in different time zones, he can wait
for 24 hours, but his decision is usually quick.
--
Best Regards
Masahiro Yamada
On 04/07/2023 23:34, Willy Tarreau wrote:
[...]
> I did and for me on this machine I don't have the problem:
>> willy@pcw:~/linux$ git status
> On branch 20230702-nolibc-series1+2_2
> Your branch is up to date with 'origin/20230702-nolibc-series1+2_2'.
>
> nothing to commit, working tree clean
> willy@pcw:~/linux$ echo blah > 2023-new-patch.mbx
Create 10k files instead of only one and you will have the above described
problem (filename completion takes ages because of untracked files not
shown by `git status`).
Kind regards,
Bernd
--
Bernd Petrovitsch Email : [email protected]
There is NO CLOUD, just other people's computers. - FSFE
LUGA : http://www.luga.at
On Tue, Jul 04, 2023 at 08:41:29PM -0400, Theodore Ts'o wrote:
> 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/...".
I *have* considered auto-cleanup of stale .mbx/.cover files using the same
logic we use with "b4 ty" to recognize when a series has been already applied.
I can turn this on as an experimental feature in the current master and see if
this is at all useful.
-K
On Wed, Jul 05, 2023 at 10:59:28AM +0900, Masahiro Yamada wrote:
> 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.
Autocomplete "works", in so far that if you type 0<TAB>, it will
autocomplete up to 000 and then ring the terminal bell, at which point
I'll type say, 1<TAB>, and then if there are previous *.patch files,
it will ring the terminal bell again, and then if you type <TAB> a
second time, it will list the possible autocompletes.
I will also say that since of "rm -f <pattern includes a '*'>" is too
easy to accidentally screwup and delete something I would care about,
my solution is "git format-patch -o /tmp/p ...", since then I can
clear out the files by typing "rm -r /tmp/p".
Cheers,
- Ted
P.S. Also note that "git format-patch" will automatically create
/tmp/p if it doesn't exist, unlike how b4 works with the -o option.
On Thu, Jul 6, 2023 at 12:34 AM Theodore Ts'o <[email protected]> wrote:
>
> On Wed, Jul 05, 2023 at 10:59:28AM +0900, Masahiro Yamada wrote:
> > 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.
>
> Autocomplete "works", in so far that if you type 0<TAB>, it will
> autocomplete up to 000 and then ring the terminal bell, at which point
> I'll type say, 1<TAB>, and then if there are previous *.patch files,
> it will ring the terminal bell again, and then if you type <TAB> a
> second time, it will list the possible autocompletes.
Of course, "autocomplete does not work" means
"it does not fill out the whole filename by
pressing the tab key just one time".
I thought it was obvious in the context of this thread.
Anyway, thanks for coming back again to point it out.
>
> I will also say that since of "rm -f <pattern includes a '*'>" is too
> easy to accidentally screwup and delete something I would care about,
> my solution is "git format-patch -o /tmp/p ...", since then I can
> clear out the files by typing "rm -r /tmp/p".
>
> Cheers,
>
> - Ted
>
> P.S. Also note that "git format-patch" will automatically create
> /tmp/p if it doesn't exist, unlike how b4 works with the -o option.
--
Best Regards
Masahiro Yamada
On Tue, Jul 4, 2023 at 5:42 PM Theodore Ts'o <[email protected]> wrote:
>
> 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
FWIW
$ b4 shazam <lore link>
is what I use to fetch and apply patches. Doesn't seem to leave behind
any mbox files.
I don't really understand why *.patch is ok to have in .gitignore but
*.mbox is not? Wouldn't autocomplete fail due to `git status` for the
exact same reason?
I don't care one way or the other, but why the inconsistency? Let's
pick one and stick with it?
--
Thanks,
~Nick Desaulniers
On Fri, 7 Jul 2023 at 11:51, Nick Desaulniers <[email protected]> wrote:
>
>
> I don't really understand why *.patch is ok to have in .gitignore but
> *.mbox is not? Wouldn't autocomplete fail due to `git status` for the
> exact same reason?
I'm sure it does. It just isn't in *my* workflow, so I don't hit it.
But if other people find the *.patch pattern annoying, I certainly
agree that that should be removed too.
Linus