* [PATCH] remote: use plural-only message for diverged branch status
@ 2026-03-14 9:12 Harald Nordgren via GitGitGadget
2026-03-14 9:16 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-03-14 16:52 ` [PATCH] remote: use plural-only message for diverged branch status Junio C Hamano
0 siblings, 2 replies; 69+ messages in thread
From: Harald Nordgren via GitGitGadget @ 2026-03-14 9:12 UTC (permalink / raw)
To: git; +Cc: Harald Nordgren, Harald Nordgren
From: Harald Nordgren <haraldnordgren@gmail.com>
Drop Q_() singular form and use _() with the plural string only.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
format_branch_comparison: diverged message has only plural case
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2239%2FHaraldNordgren%2Fformat_branch_comparison__plural-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2239/HaraldNordgren/format_branch_comparison__plural-v1
Pull-Request: https://github.com/git/git/pull/2239
remote.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/remote.c b/remote.c
index 7ca2a6501b..12136dfa23 100644
--- a/remote.c
+++ b/remote.c
@@ -2307,13 +2307,8 @@ static void format_branch_comparison(struct strbuf *sb,
_(" (use \"git pull\" to update your local branch)\n"));
} else {
strbuf_addf(sb,
- Q_("Your branch and '%s' have diverged,\n"
- "and have %d and %d different commit each, "
- "respectively.\n",
- "Your branch and '%s' have diverged,\n"
- "and have %d and %d different commits each, "
- "respectively.\n",
- ours + theirs),
+ _("Your branch and '%s' have diverged,\n"
+ "and have %d and %d different commits each, respectively.\n"),
branch_name, ours, theirs);
if (use_divergence_advice && advice_enabled(ADVICE_STATUS_HINTS))
strbuf_addstr(sb,
base-commit: dc6ecd5354dca88d51b6d6562777fc8fc10d77e1
--
gitgitgadget
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-14 9:12 [PATCH] remote: use plural-only message for diverged branch status Harald Nordgren via GitGitGadget
@ 2026-03-14 9:16 ` Harald Nordgren
2026-03-14 16:52 ` [PATCH] remote: use plural-only message for diverged branch status Junio C Hamano
1 sibling, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-03-14 9:16 UTC (permalink / raw)
To: gitgitgadget; +Cc: git, haraldnordgren
>> Harald Nordgren (2):
>> refactor format_branch_comparison in preparation
>> status: show comparison with push remote tracking branch
>>
>> remote.c | 183 ++++++++++++++++++++-------
>> t/t6040-tracking-info.sh | 262 +++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 403 insertions(+), 42 deletions(-)
>>
>>
>> base-commit: d529f3a197364881746f558e5652f0236131eb86
>> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2138%2FHaraldNordgren%2Fahead_of_main_status-v20
>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2138/HaraldNordgren/ahead_of_main_status-v20
>> Pull-Request: https://github.com/git/git/pull/2138
>>
>> Range-diff vs v19:
>>
>> 1: 451d7a4986 ! 1: bb3e00863b refactor format_branch_comparison in preparation
>> @@ remote.c: int format_tracking_info(struct branch *branch, struct strbuf *sb,
>> if (advice_enabled(ADVICE_STATUS_HINTS))
>> strbuf_addstr(sb,
>> _(" (use \"git pull\" to update your local branch)\n"));
>> -@@ remote.c: int format_tracking_info(struct branch *branch, struct strbuf *sb,
>> - "and have %d and %d different commits each, "
>> - "respectively.\n",
>> - ours + theirs),
>> + } else {
>> + strbuf_addf(sb,
>> +- Q_("Your branch and '%s' have diverged,\n"
>> +- "and have %d and %d different commit each, "
>> +- "respectively.\n",
>> +- "Your branch and '%s' have diverged,\n"
>> +- "and have %d and %d different commits each, "
>> +- "respectively.\n",
>> +- ours + theirs),
>> - base, ours, theirs);
>> ++ "Your branch and '%s' have diverged,\n"
>> ++ "and have %d and %d different commits each, respectively.\n",
>> + branch_name, ours, theirs);
>> if (show_divergence_advice &&
>> advice_enabled(ADVICE_STATUS_HINTS))
>
> Could you not mix the ours+theirs thing into the same step? Either
> make it a standalone patch to clean up before or after your main 2
> patches, or leave it totally outside the series and send it after
> this series settles.
Making a change that was left out of https://lore.kernel.org/git/xmqqzf6lqs9w.fsf@gitster.g/
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-14 9:12 [PATCH] remote: use plural-only message for diverged branch status Harald Nordgren via GitGitGadget
2026-03-14 9:16 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
@ 2026-03-14 16:52 ` Junio C Hamano
2026-03-14 18:38 ` Junio C Hamano
1 sibling, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-14 16:52 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Drop Q_() singular form and use _() with the plural string only.
I know the commit title talks about plural-only, but please make
sure that the body of the log message carries all the necessary
information to justify the change standalone. "In the else clause,
both ours and theirs are positive integers so ours+theirs must be at
least 2, hence there is no need to prepare singular and plural
variants of the message", or something to that effect, perhaps.
The patch text and the reasoning behind it does sound familiar and I
vaguely recall discussing about it ;-)
Thanks.
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> format_branch_comparison: diverged message has only plural case
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2239%2FHaraldNordgren%2Fformat_branch_comparison__plural-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2239/HaraldNordgren/format_branch_comparison__plural-v1
> Pull-Request: https://github.com/git/git/pull/2239
>
> remote.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 7ca2a6501b..12136dfa23 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -2307,13 +2307,8 @@ static void format_branch_comparison(struct strbuf *sb,
> _(" (use \"git pull\" to update your local branch)\n"));
> } else {
> strbuf_addf(sb,
> - Q_("Your branch and '%s' have diverged,\n"
> - "and have %d and %d different commit each, "
> - "respectively.\n",
> - "Your branch and '%s' have diverged,\n"
> - "and have %d and %d different commits each, "
> - "respectively.\n",
> - ours + theirs),
> + _("Your branch and '%s' have diverged,\n"
> + "and have %d and %d different commits each, respectively.\n"),
> branch_name, ours, theirs);
> if (use_divergence_advice && advice_enabled(ADVICE_STATUS_HINTS))
> strbuf_addstr(sb,
>
> base-commit: dc6ecd5354dca88d51b6d6562777fc8fc10d77e1
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-14 16:52 ` [PATCH] remote: use plural-only message for diverged branch status Junio C Hamano
@ 2026-03-14 18:38 ` Junio C Hamano
2026-03-14 20:08 ` Phillip Wood
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-14 18:38 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
Junio C Hamano <gitster@pobox.com> writes:
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Harald Nordgren <haraldnordgren@gmail.com>
>>
>> Drop Q_() singular form and use _() with the plural string only.
>
> I know the commit title talks about plural-only, but please make
> sure that the body of the log message carries all the necessary
> information to justify the change standalone. "In the else clause,
> both ours and theirs are positive integers so ours+theirs must be at
> least 2, hence there is no need to prepare singular and plural
> variants of the message", or something to that effect, perhaps.
>
> The patch text and the reasoning behind it does sound familiar and I
> vaguely recall discussing about it ;-)
>
> Thanks.
I queued the patch, tentatively with this rewritten message:
remote: don't use Q_() when it is not needed
In this code path, both ours and theirs are already known to be
positive integers, so ours + theirs will always be plural, never
using the first variant given to Q_().
Just use _() with the plural string only.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-14 18:38 ` Junio C Hamano
@ 2026-03-14 20:08 ` Phillip Wood
2026-03-15 2:08 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-03-14 20:08 UTC (permalink / raw)
To: Junio C Hamano, Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
On 14/03/2026 18:38, Junio C Hamano wrote:
>
> remote: don't use Q_() when it is not needed
>
> In this code path, both ours and theirs are already known to be
> positive integers, so ours + theirs will always be plural, never
> using the first variant given to Q_().
>
> Just use _() with the plural string only.
There can be more than one form of the plural string though. The gettext
manual has the following example of the Polish translation of "file" for
different numbers of files [1]
1 plik
2,3,4 pliki
5-21 plików
22-24 pliki
25-31 plików
ngettext() handles that correctly, translating a single string without
an associated count will not.
Thanks
Phillip
[1]
https://www.gnu.org/software/gettext/manual/gettext.html#Additional-functions-for-plural-forms
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-14 20:08 ` Phillip Wood
@ 2026-03-15 2:08 ` Junio C Hamano
2026-03-16 10:49 ` Phillip Wood
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-15 2:08 UTC (permalink / raw)
To: Phillip Wood; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
> There can be more than one form of the plural string though. The gettext
> manual has the following example of the Polish translation of "file" for
> different numbers of files [1]
>
> 1 plik
> 2,3,4 pliki
> 5-21 plików
> 22-24 pliki
> 25-31 plików
>
> ngettext() handles that correctly, translating a single string without
> an associated count will not.
That is a very interesting example, and a valid reason to have me
retract the #leftoverbits that led to the patch being discussed.
But wouldn't that lead to an awkward conclusion, i.e., hits from
"git grep '[^Q]_("[^"]*%[id]' \*.c" are potential bugs that need to
be updated to use ngettext().
Of course, we need to exclude messages like "the error code %d was
returned" and "you have a bug on line %d", but there seem to be real
errors in randomly selected hits from the "git grep" output, e.g.,
add-patch.c: _("Split into %d hunks."),
archive-zip.c: return error(_("path too long (%d chars, SHA1: %s): %s"),
builtin/checkout.c: die(_("'%s' matched multiple (%d) remote tracking branches"),
builtin/credential-store.c: die_errno(_("unable to get credential storage lock in %d ms"), timeout_ms);
builtin/describe.c: _("found %i tags; gave up search at %s\n"),
builtin/fsck.c: fprintf_ln(stderr, _("Checking connectivity (%d objects)"), max);
You can notice that I started from 'a' and stopped very early in 'b'
;-).
Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-15 2:08 ` Junio C Hamano
@ 2026-03-16 10:49 ` Phillip Wood
2026-03-16 17:06 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-03-16 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
On 15/03/2026 02:08, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> There can be more than one form of the plural string though. The gettext
>> manual has the following example of the Polish translation of "file" for
>> different numbers of files [1]
>>
>> 1 plik
>> 2,3,4 pliki
>> 5-21 plików
>> 22-24 pliki
>> 25-31 plików
>>
>> ngettext() handles that correctly, translating a single string without
>> an associated count will not.
>
> That is a very interesting example, and a valid reason to have me
> retract the #leftoverbits that led to the patch being discussed.
>
> But wouldn't that lead to an awkward conclusion, i.e., hits from
> "git grep '[^Q]_("[^"]*%[id]' \*.c" are potential bugs that need to
> be updated to use ngettext().
I think it does - maybe we should suggest fixing these as a miroproject
for GSoC and Outreachy? It certainly looks like there are plenty of them.
Thanks
Phillip
> Of course, we need to exclude messages like "the error code %d was
> returned" and "you have a bug on line %d", but there seem to be real
> errors in randomly selected hits from the "git grep" output, e.g.,
>
> add-patch.c: _("Split into %d hunks."),
> archive-zip.c: return error(_("path too long (%d chars, SHA1: %s): %s"),
> builtin/checkout.c: die(_("'%s' matched multiple (%d) remote tracking branches"),
> builtin/credential-store.c: die_errno(_("unable to get credential storage lock in %d ms"), timeout_ms);
> builtin/describe.c: _("found %i tags; gave up search at %s\n"),
> builtin/fsck.c: fprintf_ln(stderr, _("Checking connectivity (%d objects)"), max);
>
> You can notice that I started from 'a' and stopped very early in 'b'
> ;-).
>
> Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-16 10:49 ` Phillip Wood
@ 2026-03-16 17:06 ` Junio C Hamano
2026-03-25 4:29 ` Kaartic Sivaraam
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-16 17:06 UTC (permalink / raw)
To: Phillip Wood; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 15/03/2026 02:08, Junio C Hamano wrote:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>>
>>> There can be more than one form of the plural string though. The gettext
>>> manual has the following example of the Polish translation of "file" for
>>> different numbers of files [1]
>>>
>>> 1 plik
>>> 2,3,4 pliki
>>> 5-21 plików
>>> 22-24 pliki
>>> 25-31 plików
>>>
>>> ngettext() handles that correctly, translating a single string without
>>> an associated count will not.
>>
>> That is a very interesting example, and a valid reason to have me
>> retract the #leftoverbits that led to the patch being discussed.
>>
>> But wouldn't that lead to an awkward conclusion, i.e., hits from
>> "git grep '[^Q]_("[^"]*%[id]' \*.c" are potential bugs that need to
>> be updated to use ngettext().
>
> I think it does - maybe we should suggest fixing these as a miroproject
> for GSoC and Outreachy? It certainly looks like there are plenty of them.
That would be great. It needs a bit of thinking, the required
change for each of them is quite small, and there are tons of them.
An ideal candidate for a microproject.
Adding it to the list of microproject ideas is a good #leftoverbits
as well.
>
> Thanks
>
> Phillip
>
>> Of course, we need to exclude messages like "the error code %d was
>> returned" and "you have a bug on line %d", but there seem to be real
>> errors in randomly selected hits from the "git grep" output, e.g.,
>>
>> add-patch.c: _("Split into %d hunks."),
>> archive-zip.c: return error(_("path too long (%d chars, SHA1: %s): %s"),
>> builtin/checkout.c: die(_("'%s' matched multiple (%d) remote tracking branches"),
>> builtin/credential-store.c: die_errno(_("unable to get credential storage lock in %d ms"), timeout_ms);
>> builtin/describe.c: _("found %i tags; gave up search at %s\n"),
>> builtin/fsck.c: fprintf_ln(stderr, _("Checking connectivity (%d objects)"), max);
>>
>> You can notice that I started from 'a' and stopped very early in 'b'
>> ;-).
>>
>> Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] remote: use plural-only message for diverged branch status
2026-03-16 17:06 ` Junio C Hamano
@ 2026-03-25 4:29 ` Kaartic Sivaraam
0 siblings, 0 replies; 69+ messages in thread
From: Kaartic Sivaraam @ 2026-03-25 4:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phillip Wood, Harald Nordgren via GitGitGadget, git,
Harald Nordgren
On Mon, Mar 16, 2026 at 10:37 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> >> But wouldn't that lead to an awkward conclusion, i.e., hits from
> >> "git grep '[^Q]_("[^"]*%[id]' \*.c" are potential bugs that need to
> >> be updated to use ngettext().
> >
> > I think it does - maybe we should suggest fixing these as a miroproject
> > for GSoC and Outreachy? It certainly looks like there are plenty of them.
>
> That would be great. It needs a bit of thinking, the required
> change for each of them is quite small, and there are tons of them.
> An ideal candidate for a microproject.
>
> Adding it to the list of microproject ideas is a good #leftoverbits
> as well.
>
This has been added to the microprojects list now. Do check and
let us know in case it needs any tweaks.
https://git.github.io/SoC-2026-Microprojects#fix-improper-pluralization-to-use-ngettext
Thanks.
--
Sivaraam
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] fetch: add fetch.pruneLocalBranches config
@ 2026-05-03 22:39 Junio C Hamano
2026-05-04 18:28 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-05-03 22:39 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Introduce a tri-state config option that, when --prune (or
> fetch.prune / remote.<name>.prune) removes a remote-tracking
> ref, also deletes local branches whose configured upstream is
> that ref.
>
> Values:
> - false (default): no change in behavior.
> - safe: delete only if the local tip is reachable from the
> upstream tip, preserving any unpushed work.
> - force: delete unconditionally; recoverable only via reflog.
>
> The currently checked-out branch is always preserved.
I do like the feature that allows you to identify which local
branches are already merged and prune them. It will help users keep
their local branch namespace clean.
I however do not like to see the feature tied to "fetch". By this,
I do not mean I do not want an option to trigger the feature when
"git fetch" is run. What I mean is that users should have an option
to prune merged branches without having to fetch first. And you can
then optionally trigger that machinery from "git fetch".
Of course they aleady can do something silly like
$ git branch -d $(git branch --list | sed -e 's/^..//')
and remove all the merged branches, but compared to what is
presented here, one thing missing is that you allow pruning the
local branches that are merged only to remote-tracking branches from
a single remote.
To break the feature down to make it easier to use by our users with
various needs and workflows, we would benefit from having a
collection of smaller features that can be composed, like these:
* "git branch --forked <remote>" lists local branches that build on
something taken from <remote>s. The option can be given multiple
times to make a union of the results from individual "--forked
<remote>".
- <remote> may be a name of a remote, e.g., "origin" to mean all
the remote-tracking branches "refs/remotes/origin/*",
- <remote> may be "origin/master" to name a specific
remote-tracking branch.
- There may be other handy things to cover with <remote>, like
"--all" that may act as if you listed all the available
<remote> on the command line.
* "git branch --prune-merged <remote>..." is a short-hand for "git
branch -d $(git branch --forked <remote>...".
* "git fetch/pull --prune-merged <remote>" can trigger "git branch
--prune-merged <remote>" after "git fetch" successfully updates
the remote-tracking branches, which should be equivalent to what
you have here..
Some local branches that fork from remote and have their initial
round already merged may not want to be pruned, however. You may
have multi-stage development plans for that topic, and you know
already the second phase would want to build on top of the initial
round, not a random version of the mainline with many topics from
other folks merged in. So you'd rather want to keep the topic
branch around after your initial round has been merged to the
upstream before you start the second phase. This is especially true
if your topic is designed to apply to an existing release (in other
words, a bugfix) and you want to keep the second and subsequent
rounds of the topic to be applicable to the same target version
without contaminating the topic with irrelevant features from others
that happened to have been developed and merged upstream around the
same time.
And we'd need to cater to their needs. By this, I do not mean "they
do not have to use --prune-merged", but by giving them a way to say
"this branch should not be auto-pruned with --prune-merged".
^ permalink raw reply [flat|nested] 69+ messages in thread* [PATCH] checkout: add --autostash option for branch switching
2026-05-03 22:39 [PATCH] fetch: add fetch.pruneLocalBranches config Junio C Hamano
@ 2026-05-04 18:28 ` Harald Nordgren
2026-05-10 1:01 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-05-04 18:28 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren
> I do like the feature that allows you to identify which local
> branches are already merged and prune them. It will help users keep
> their local branch namespace clean.
Nice to hear!
> To break the feature down to make it easier to use by our users with
> various needs and workflows, we would benefit from having a
> collection of smaller features that can be composed, like these:
I gave it a shot to implement these, and then I ran it one some local repos
it works really nicely!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-05-04 18:28 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
@ 2026-05-10 1:01 ` Junio C Hamano
0 siblings, 0 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-05-10 1:01 UTC (permalink / raw)
To: Harald Nordgren; +Cc: git, gitgitgadget
Harald Nordgren <haraldnordgren@gmail.com> writes:
>> I do like the feature that allows you to identify which local
>> branches are already merged and prune them. It will help users keep
>> their local branch namespace clean.
>
> Nice to hear!
>
>> To break the feature down to make it easier to use by our users with
>> various needs and workflows, we would benefit from having a
>> collection of smaller features that can be composed, like these:
>
> I gave it a shot to implement these, and then I ran it one some local repos
> it works really nicely!
>
>
> Harald
It was baffling to see a message with the subject "checkout: add
--autostash" as your reponse to my message that was a response to
"fetch: add fetch.pruneLocalBranches".
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v5] checkout: extend --track with a "fetch" mode to refresh start-point
@ 2026-05-03 20:59 Junio C Hamano
2026-05-03 22:32 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-05-03 20:59 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget
Cc: git, Ramsay Jones, D. Ben Knoble, Kristoffer Haugsbakk,
Marc Branchaud, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> A common workflow is:
>
> git fetch origin
> git checkout -b new_branch --track origin/some-branch
>
> The first command exists so the second sees an up-to-date view of the
> remote. If it is forgotten, origin/some-branch points at a stale
> commit and the new local branch is created from the wrong start
> point.
As I pointed out multiple times, I prefer not to see this called
"wrong". Even if you did not "forget", somebody may be pushing
after you fetched and you may end up forking from a "stale" commit.
So not fetching is not inherently "wrong", simply because that is
how real world works. Multiple people working in a distributed
environment does not give you absolute garantee that you will be "up
to date", ever, which makes it wrong to call anything that is not
"up to date" a "wrong starting point".
> This only matters when the user is setting up tracking and
> expects the new branch to start at the freshest tip; for a one-off
> checkout of an arbitrary commit there is no reason to "freshen" the
> start-point.
I do not think "arbitrary" fits in this workflow description.
If anything, "I'd take anything that the remote repository happens
to have at the tip, even without having a chance to sanity checke if
that is a good starting point" is more appropriate workflow to be
described with a word "arbitrary commit".
If you are checking out without forking from there, you'd more
likely be checking out the "latest" you have fetched from the other
side, often knowing exactly what it is after checking it with "git
show origin/$topic".
> Tie the new behavior to --track for that reason:
Notice that the reader hasn't heard what "the new behaviour" is up
to this point yet?
How about rewriting everything up to and including this "Tie the new
..." line perhaps like so:
If you want to fork your topic branch from the very latest of
the tip of a branch your remote has, you would do:
git fetch origin some-branch
git checkout -b new_branch --track origin/some-branch
Extend the "--track" option of "git checkout" and allow users to
write
git checkout --track=fetch -b new_branch origin/some_branch
to (1) fetch 'some-branch' from the remote 'origin', updating
the remote-tracking branch 'origin/some-branch', (2) arrange
subsequent 'git pull' on 'new_branch' to interact with
'origin/some_branch' and (3) fork 'new_branch' from it.
In the value of the '--track' option, 'fetch' can be combined
with ...
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v16 0/5] checkout: 'autostash' for branch switching
@ 2026-04-29 10:02 Phillip Wood
2026-04-29 11:11 ` [PATCH] checkout: add --autostash option " Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-29 10:02 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 28/04/2026 19:39, Harald Nordgren via GitGitGadget wrote:
> * Updated the git checkout and git switch docs to show the actual output
> when using -m to carry local changes across a branch switch, and changed
> "would carry" to "will carry".
> * Rewrote the merge-conflict example in both docs to match the new, more
> concise message printed on autostash conflicts.
> * Replaced the show_unpack_errors flag and old_commit parameter in
> merge_working_tree()/init_topts() with a plain quiet boolean, so the
> caller decides directly whether to suppress unpack errors.
> * Tightened the 'checkout -m with dirty tree' test by replacing a printf
> with a heredoc.
> * Made the 'checkout -m creates a recoverable stash on conflict' test also
> assert the reflog subject of the new stash entry.
> * Replaced two test_grep calls in the 'checkout -m which would overwrite
> untracked file' test with a single test_cmp, which also catches a
> regression where the "would be overwritten" message could end up printed
> twice.
That all sounds good and the range-diff below looks as I would expect it
to. I've left some suggestions for possible future work on patch 5 but I
think this is ready to be merged as-is.
Thanks for working on it
Phillip
> Harald Nordgren (5):
> stash: add --label-ours, --label-theirs, --label-base for apply
> sequencer: allow create_autostash to run silently
> sequencer: teach autostash apply to take optional conflict marker
> labels
> checkout: rollback lock on early returns in merge_working_tree
> checkout -m: autostash when switching branches
>
> Documentation/git-checkout.adoc | 55 +++++------
> Documentation/git-stash.adoc | 11 ++-
> Documentation/git-switch.adoc | 36 ++++---
> builtin/checkout.c | 166 +++++++++++++++-----------------
> builtin/commit.c | 3 +-
> builtin/merge.c | 15 ++-
> builtin/stash.c | 28 ++++--
> sequencer.c | 69 +++++++++----
> sequencer.h | 7 +-
> t/t3420-rebase-autostash.sh | 16 +--
> t/t3903-stash.sh | 24 +++++
> t/t7201-co.sh | 71 +++++++++++++-
> t/t7600-merge.sh | 3 +-
> xdiff-interface.c | 12 +++
> xdiff-interface.h | 1 +
> xdiff/xmerge.c | 6 +-
> 16 files changed, 343 insertions(+), 180 deletions(-)
>
>
> base-commit: 94f057755b7941b321fd11fec1b2e3ca5313a4e0
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2234%2FHaraldNordgren%2Fcheckout_autostash-v16
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2234/HaraldNordgren/checkout_autostash-v16
> Pull-Request: https://github.com/git/git/pull/2234
>
> Range-diff vs v15:
>
> 1: aba8e6a9dc = 1: aba8e6a9dc stash: add --label-ours, --label-theirs, --label-base for apply
> 2: 89e0bfa803 = 2: 89e0bfa803 sequencer: allow create_autostash to run silently
> 3: a428ce7328 = 3: a428ce7328 sequencer: teach autostash apply to take optional conflict marker labels
> 4: f358424085 = 4: f358424085 checkout: rollback lock on early returns in merge_working_tree
> 5: 96b14db827 ! 5: 07d25fda91 checkout -m: autostash when switching branches
> @@ Documentation/git-checkout.adoc: $ git checkout mytopic
>
> -You can give the `-m` flag to the command, which would try a
> -three-way merge:
> -+You can give the `-m` flag to the command, which would carry your local
> ++You can give the `-m` flag to the command, which will carry your local
> +changes to the new branch:
>
> ------------
> $ git checkout -m mytopic
> -Auto-merging frotz
> ++Applied autostash.
> +Switched to branch 'mytopic'
> ++The following paths have local changes:
> ++M frotz
> ------------
>
> -After this three-way merge, the local modifications are _not_
> @@ Documentation/git-checkout.adoc: $ git checkout mytopic
>
> -When a merge conflict happens during switching branches with
> -the `-m` option, you would see something like this:
> -+When the `--merge` (`-m`) option is in effect and the locally
> -+modified files overlap with files that need to be updated by the
> -+branch switch, the changes are stashed and reapplied after the
> -+switch. If this process results in conflicts, a stash entry is saved
> -+and made available in `git stash list`:
> ++When the `--merge` (`-m`) option is given and the local changes
> ++overlap with the changes in the branch we're switching to, the
> ++changes are stashed and reapplied after the switch. If this
> ++process results in conflicts, the stash entry is saved and a
> ++message is printed:
>
> ------------
> $ git checkout -m mytopic
> @@ Documentation/git-checkout.adoc: $ git checkout mytopic
> -ERROR: Merge conflict in frotz
> -fatal: merge program failed
> -------------
> -+Your local changes are stashed, however, applying it to carry
> -+forward your local changes resulted in conflicts:
> -
> +-
> -At this point, `git diff` shows the changes cleanly merged as in
> -the previous example, as well as the changes in the conflicted
> -files. Edit and resolve the conflict and mark it resolved with
> -`git add` as usual:
> -+ - You can try resolving them now. If you resolved them
> -+ successfully, discard the stash entry with "git stash drop".
> -
> -+ - Alternatively you can "git reset --hard" if you do not want
> -+ to deal with them right now, and later "git stash pop" to
> -+ recover your local changes.
> - ------------
> +-
> +-------------
> -$ edit frotz
> -$ git add frotz
> --------------
> -+
> -+You can try resolving the conflicts now. Edit the conflicting files
> -+and mark them resolved with `git add` as usual, then run `git stash
> -+drop` to discard the stash entry. Alternatively, you can clear the
> -+working tree with `git reset --hard` and recover your local changes
> -+later with `git stash pop`.
> ++Your local changes are stashed, however applying them
> ++resulted in conflicts. You can either resolve the conflicts
> ++and then discard the stash with "git stash drop", or, if you
> ++do not want to resolve them now, run "git reset --hard" and
> ++apply the local changes later by running "git stash pop".
> + ------------
>
> CONFIGURATION
> - -------------
>
> ## Documentation/git-switch.adoc ##
> @@ Documentation/git-switch.adoc: variable.
> @@ Documentation/git-switch.adoc: $ git switch mytopic
>
> -You can give the `-m` flag to the command, which would try a three-way
> -merge:
> -+You can give the `-m` flag to the command, which would carry your local
> ++You can give the `-m` flag to the command, which will carry your local
> +changes to the new branch:
>
> ------------
> $ git switch -m mytopic
> -Auto-merging frotz
> ++Applied autostash.
> +Switched to branch 'mytopic'
> ++The following paths have local changes:
> ++M frotz
> ------------
>
> -After this three-way merge, the local modifications are _not_
> @@ builtin/checkout.c: struct checkout_opts {
> char *name; /* The short name used */
> char *path; /* The full name of a real branch */
> @@ builtin/checkout.c: static void setup_branch_path(struct branch_info *branch)
> + branch->path = strbuf_detach(&buf, NULL);
> + }
>
> - static void init_topts(struct unpack_trees_options *topts, int merge,
> +-static void init_topts(struct unpack_trees_options *topts, int merge,
> ++static void init_topts(struct unpack_trees_options *topts,
> int show_progress, int overwrite_ignore,
> - struct commit *old_commit)
> -+ struct commit *old_commit, bool show_unpack_errors)
> ++ bool quiet)
> {
> memset(topts, 0, sizeof(*topts));
> topts->head_idx = -1;
> @@ builtin/checkout.c: static void init_topts(struct unpack_trees_options *topts, i
> topts->update = 1;
> topts->merge = 1;
> - topts->quiet = merge && old_commit;
> -+ topts->quiet = merge && old_commit && !show_unpack_errors;
> ++ topts->quiet = quiet;
> topts->verbose_update = show_progress;
> topts->fn = twoway_merge;
> topts->preserve_ignored = !overwrite_ignore;
> @@ builtin/checkout.c: static void init_topts(struct unpack_trees_options *topts, i
> static int merge_working_tree(const struct checkout_opts *opts,
> struct branch_info *old_branch_info,
> struct branch_info *new_branch_info,
> -- int *writeout_error)
> -+ int *writeout_error,
> -+ bool show_unpack_errors)
> ++ bool quiet,
> + int *writeout_error)
> {
> int ret;
> - struct lock_file lock_file = LOCK_INIT;
> @@ builtin/checkout.c: static int merge_working_tree(const struct checkout_opts *opts,
> + }
>
> /* 2-way merge to the new branch */
> - init_topts(&topts, opts->merge, opts->show_progress,
> +- init_topts(&topts, opts->merge, opts->show_progress,
> - opts->overwrite_ignore, old_branch_info->commit);
> -+ opts->overwrite_ignore, old_branch_info->commit,
> -+ show_unpack_errors);
> ++ init_topts(&topts, opts->show_progress,
> ++ opts->overwrite_ignore, quiet);
> init_checkout_metadata(&topts.meta, new_branch_info->refname,
> new_branch_info->commit ?
> &new_branch_info->commit->object.oid :
> @@ builtin/checkout.c: static int switch_branches(const struct checkout_opts *opts,
> if (do_merge) {
> - ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info,
> -+ &writeout_error, false);
> ++ opts->merge, &writeout_error);
> + if (ret == MERGE_WORKING_TREE_UNPACK_FAILED && opts->merge) {
> + strbuf_addf(&autostash_msg,
> + "autostash while switching to '%s'",
> @@ builtin/checkout.c: static int switch_branches(const struct checkout_opts *opts,
> + autostash_msg.buf, true);
> + created_autostash = 1;
> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info,
> -+ &writeout_error, true);
> ++ false, &writeout_error);
> + }
> + if (created_autostash) {
> + if (opts->conflict_style >= 0) {
> @@ t/t7201-co.sh: test_expect_success 'checkout -m with dirty tree' '
> test "$(git symbolic-ref HEAD)" = "refs/heads/side" &&
>
> - printf "M\t%s\n" one >expect.messages &&
> -+ printf "The following paths have local changes:\nM\t%s\n" one >expect.messages &&
> ++ cat >expect.messages <<-\EOF &&
> ++ The following paths have local changes:
> ++ M one
> ++ EOF
> test_cmp expect.messages messages &&
>
> fill "M one" "A three" "D two" >expect.main &&
> @@ t/t7201-co.sh: test_expect_success 'checkout --merge --conflict=diff3 <branch>'
> + test_grep "git stash drop" actual &&
> + test_grep "git stash pop" actual &&
> + test_grep "The following paths have local changes" actual &&
> -+ git show --format=%B --diff-merges=1 refs/stash >actual &&
> ++ git log -p -1 --format="%gs%n%B" -g --diff-merges=1 refs/stash >actual &&
> + sed /^index/d actual >actual.trimmed &&
> + cat >expect <<-EOF &&
> ++ autostash while switching to ${SQ}side${SQ}
> + On main: autostash while switching to ${SQ}side${SQ}
> +
> + diff --git a/one b/one
> @@ t/t7201-co.sh: test_expect_success 'checkout --merge --conflict=diff3 <branch>'
> + >another-file.t &&
> + fill 1 2 3 4 5 >one &&
> + test_must_fail git checkout -m @{-1} 2>err &&
> -+ test_grep "would be overwritten by checkout" err &&
> -+ test_grep "another-file.t" err
> ++ q_to_tab >expect <<-\EOF &&
> ++ error: The following untracked working tree files would be overwritten by checkout:
> ++ Qanother-file.t
> ++ Please move or remove them before you switch branches.
> ++ Aborting
> ++ Applied autostash.
> ++ EOF
> ++ test_cmp expect err
> +'
> +
> test_expect_success 'switch to another branch while carrying a deletion' '
>
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v15 5/5] checkout -m: autostash when switching branches
@ 2026-04-28 9:35 Phillip Wood
2026-04-28 18:08 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-28 9:35 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 24/04/2026 22:10, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When switching branches with "git checkout -m", the attempted merge
> of local modifications may cause conflicts with the changes made on
> the other branch, which the user may not want to (or may not be able
> to) resolve right now. Because there is no easy way to recover from
> this situation, we discouraged users from using "checkout -m" unless
> they are certain their changes are trivial and within their ability
> to resolve conflicts.
>
> Teach the -m flow to create a temporary stash before switching and
> reapply it after. On success, the stash is silently applied and
> the list of locally modified paths is shown, same as a successful
> "git checkout" without "-m".
>
> If reapplying causes conflicts, the stash is kept and the user is
> told they can resolve and run "git stash drop", or run "git reset
> --hard" and later "git stash pop" to recover their changes.
This is looking good, there are just a few small issues. Hopefully the
next iteration will be the last.
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> Documentation/git-checkout.adoc | 58 ++++++------
> Documentation/git-switch.adoc | 33 +++----
> builtin/checkout.c | 160 ++++++++++++++------------------
> sequencer.c | 14 ++-
> t/t3420-rebase-autostash.sh | 16 ++--
> t/t7201-co.sh | 61 +++++++++++-
> t/t7600-merge.sh | 3 +-
> xdiff-interface.c | 12 +++
> xdiff-interface.h | 1 +
> 9 files changed, 211 insertions(+), 147 deletions(-)
>
> diff --git a/Documentation/git-checkout.adoc b/Documentation/git-checkout.adoc
> index 43ccf47cf6..70dd211ee3 100644
> --- a/Documentation/git-checkout.adoc
> +++ b/Documentation/git-checkout.adoc
> @@ -251,20 +251,19 @@ working tree, by copying them from elsewhere, extracting a tarball, etc.
> are different between the current branch and the branch to
> which you are switching, the command refuses to switch
> branches in order to preserve your modifications in context.
> - However, with this option, a three-way merge between the current
> - branch, your working tree contents, and the new branch
> - is done, and you will be on the new branch.
> -+
> -When a merge conflict happens, the index entries for conflicting
> -paths are left unmerged, and you need to resolve the conflicts
> -and mark the resolved paths with `git add` (or `git rm` if the merge
> -should result in deletion of the path).
> + With this option, the conflicting local changes are
> + automatically stashed before the switch and reapplied
> + afterwards. If the local changes do not overlap with the
> + differences between branches, the switch proceeds without
> + stashing. If reapplying the stash results in conflicts, the
> + entry is saved to the stash list. Resolve the conflicts
> + and run `git stash drop` when done, or clear the working
> + tree (e.g. with `git reset --hard`) before running `git stash
> + pop` later to re-apply your changes.
> +
> When checking out paths from the index, this option lets you recreate
> the conflicted merge in the specified paths. This option cannot be
> used when checking out paths from a tree-ish.
> -+
> -When switching branches with `--merge`, staged changes may be lost.
>
> `--conflict=<style>`::
> The same as `--merge` option above, but changes the way the
> @@ -578,39 +577,44 @@ $ git checkout mytopic
> error: You have local changes to 'frotz'; not switching branches.
> ------------
>
> -You can give the `-m` flag to the command, which would try a
> -three-way merge:
> +You can give the `-m` flag to the command, which would carry your local
s/would/will/ or s/would carry/carries/
> +changes to the new branch:
>
> ------------
> $ git checkout -m mytopic
> -Auto-merging frotz
> +Switched to branch 'mytopic'
> ------------
>
> -After this three-way merge, the local modifications are _not_
> +After the switch, the local modifications are reapplied and are _not_
> registered in your index file,
We don't test this but we do test that "git stash apply" does not update
the index so we should be fine.
> so `git diff` would show you what
> changes you made since the tip of the new branch.
>
> === 3. Merge conflict
>
> -When a merge conflict happens during switching branches with
> -the `-m` option, you would see something like this:
> +When the `--merge` (`-m`) option is in effect and the locally
> +modified files overlap with files that need to be updated by the
> +branch switch,
It is the changes in the files overlapping that causes the merge
conflict, not the files overlapping
When the `--merge` (`-m`) option is given and the local changes
overlap with the changes in the branch we're switching to,
> the changes are stashed and reapplied after the
> +switch. If this process results in conflicts, a stash entry is saved
s/a/the/
> +and made available in `git stash list`:
I'd drop this line and say instead "a message is printed"
> ------------
> $ git checkout -m mytopic
> -Auto-merging frotz
> -ERROR: Merge conflict in frotz
> -fatal: merge program failed
> -------------
> +Your local changes are stashed, however, applying it to carry
> +forward your local changes resulted in conflicts:
>
> -At this point, `git diff` shows the changes cleanly merged as in
> -the previous example, as well as the changes in the conflicted
> -files. Edit and resolve the conflict and mark it resolved with
> -`git add` as usual:
> + - You can try resolving them now. If you resolved them
> + successfully, discard the stash entry with "git stash drop".
>
> + - Alternatively you can "git reset --hard" if you do not want
> + to deal with them right now, and later "git stash pop" to
> + recover your local changes.
This needs updating to match the new conflict advice.
> ------------
> -$ edit frotz
> -$ git add frotz
> -------------
> +
> +You can try resolving the conflicts now. Edit the conflicting files
> +and mark them resolved with `git add` as usual, then run `git stash
> +drop` to discard the stash entry. Alternatively, you can clear the
> +working tree with `git reset --hard` and recover your local changes
> +later with `git stash pop`.
Is this documentation, or program output?
If you've not done so already it would be well worth checking the
generated git-checkout.html and the man page
> CONFIGURATION
> -------------
> diff --git a/Documentation/git-switch.adoc b/Documentation/git-switch.adoc
> index 87707e9265..ee58a4d0fd 100644
> --- a/Documentation/git-switch.adoc
> +++ b/Documentation/git-switch.adoc
> @@ -123,18 +123,19 @@ variable.
>
> `-m`::
> `--merge`::
> - If you have local modifications to one or more files that are
> - different between the current branch and the branch to which
> - you are switching, the command refuses to switch branches in
> - order to preserve your modifications in context. However,
> - with this option, a three-way merge between the current
> - branch, your working tree contents, and the new branch is
> - done, and you will be on the new branch.
> -+
> -When a merge conflict happens, the index entries for conflicting
> -paths are left unmerged, and you need to resolve the conflicts
> -and mark the resolved paths with `git add` (or `git rm` if the merge
> -should result in deletion of the path).
> + If you have local modifications to one or more files that
> + are different between the current branch and the branch to
> + which you are switching, the command normally refuses to
> + switch branches in order to preserve your modifications in
> + context. However, with this option, the conflicting local
> + changes are automatically stashed before the switch and
> + reapplied afterwards. If the local changes do not overlap
> + with the differences between branches, the switch proceeds
> + without stashing. If reapplying the stash results in
> + conflicts, the entry is saved to the stash list. Resolve
> + the conflicts and run `git stash drop` when done, or clear
> + the working tree (e.g. with `git reset --hard`) before
> + running `git stash pop` later to re-apply your changes.
>
> `--conflict=<style>`::
> The same as `--merge` option above, but changes the way the
> @@ -217,15 +218,15 @@ $ git switch mytopic
> error: You have local changes to 'frotz'; not switching branches.
> ------------
>
> -You can give the `-m` flag to the command, which would try a three-way
> -merge:
> +You can give the `-m` flag to the command, which would carry your local
> +changes to the new branch:
Same comment as for git-checkout.adoc
> ------------
> $ git switch -m mytopic
> -Auto-merging frotz
> +Switched to branch 'mytopic'
Don't we show the modified files as well now?
> ------------
>
> -After this three-way merge, the local modifications are _not_
> +After the switch, the local modifications are reapplied and are _not_
> registered in your index file, so `git diff` would show you what
> changes you made since the tip of the new branch.
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> @@ -755,7 +757,7 @@ static void setup_branch_path(struct branch_info *branch)
>
> static void init_topts(struct unpack_trees_options *topts, int merge,
> int show_progress, int overwrite_ignore,
> - struct commit *old_commit)
> + struct commit *old_commit, bool show_unpack_errors)
As this function only sets up the flags for unpack_trees() I think we
could call this "quiet" or "show_errors"
> {
> memset(topts, 0, sizeof(*topts));
> topts->head_idx = -1;
> @@ -767,7 +769,7 @@ static void init_topts(struct unpack_trees_options *topts, int merge,
> topts->initial_checkout = is_index_unborn(the_repository->index);
> topts->update = 1;
> topts->merge = 1;
> - topts->quiet = merge && old_commit;
> + topts->quiet = merge && old_commit && !show_unpack_errors;
We've added a function parameter for this option but then we ignore it
unless "merge" and "old_commit" are true which is confusing. The reason
we used to check those was to set "quiet" automatically but we can't do
that now, so why not just use the value the call requested?
> topts->verbose_update = show_progress;
> topts->fn = twoway_merge;
> topts->preserve_ignored = !overwrite_ignore;
> @@ -776,7 +778,8 @@ static void init_topts(struct unpack_trees_options *topts, int merge,
> static int merge_working_tree(const struct checkout_opts *opts,
> struct branch_info *old_branch_info,
> struct branch_info *new_branch_info,
> - int *writeout_error)
> + int *writeout_error,
This is an "out" parameter, so it would make sense to keep it at the end
of the parameter list.
> + bool show_unpack_errors)
> {
> @@ -853,90 +857,8 @@ static int merge_working_tree(const struct checkout_opts *opts,
> ret = unpack_trees(2, trees, &topts);
> clear_unpack_trees_porcelain(&topts);
> if (ret == -1) {
> [...]
> + rollback_lock_file(&lock_file);
> + return MERGE_WORKING_TREE_UNPACK_FAILED;
We now use a unique return value when unpack_trees() fails - good.
> }
> }
>
> @@ -1181,6 +1103,10 @@ static int switch_branches(const struct checkout_opts *opts,
> struct object_id rev;
> int flag, writeout_error = 0;
> int do_merge = 1;
> + int created_autostash = 0;
> + struct strbuf old_commit_shortname = STRBUF_INIT;
> + struct strbuf autostash_msg = STRBUF_INIT;
> + const char *stash_label_base = NULL;
>
> trace2_cmd_mode("branch");
>
> @@ -1218,11 +1144,49 @@ static int switch_branches(const struct checkout_opts *opts,
> [...]
> if (do_merge) {
> - ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info,
> + &writeout_error, false);
> + if (ret == MERGE_WORKING_TREE_UNPACK_FAILED && opts->merge) {
> + strbuf_addf(&autostash_msg,
> + "autostash while switching to '%s'",
In an ideal world we'd create a message that said
On <new branch>: autostash while switching from '<old branch>'
However I as discussed on patch 3, that would require us to be able to
override the branch name when creating a stash as that's where the "On
<branch>: " prefix gets added.
> + new_branch_info->name);
> + create_autostash_ref(the_repository,
> + "CHECKOUT_AUTOSTASH_HEAD",
> + autostash_msg.buf, true);
> + created_autostash = 1;
> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info,
> + &writeout_error, true);
> + }
> + if (created_autostash) {
> + if (opts->conflict_style >= 0) {
> + struct strbuf cfg = STRBUF_INIT;
> + strbuf_addf(&cfg, "merge.conflictStyle=%s",
> + conflict_style_name(opts->conflict_style));
> + git_config_push_parameter(cfg.buf);
> + strbuf_release(&cfg);
> + }
> + apply_autostash_ref(the_repository,
> + "CHECKOUT_AUTOSTASH_HEAD",
> + new_branch_info->name,
> + "local",
> + stash_label_base,
> + autostash_msg.buf);
> + }
We now have a single place where we restore the stashed changes - good
> diff --git a/sequencer.c b/sequencer.c
> index 7c0376d9e4..746f85a442 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4765,15 +4765,19 @@ static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply,
> strvec_push(&store.args, stash_oid);
> if (run_command(&store))
> ret = error(_("cannot store %s"), stash_oid);
> + else if (attempt_apply)
> + fprintf(stderr,
> + _("Your local changes are stashed, however applying them\n"
> + "resulted in conflicts. You can either resolve the conflicts\n"
> + "and then discard the stash with \"git stash drop\", or, if you\n"
> + "do not want to resolve them now, run \"git reset --hard\" and\n"
> + "apply the local changes later by running \"git stash pop\".\n"));
> else
> fprintf(stderr,
> - _("%s\n"
> + _("Autostash exists; creating a new stash entry.\n"
> "Your changes are safe in the stash.\n"
> "You can run \"git stash pop\" or"
> - " \"git stash drop\" at any time.\n"),
> - attempt_apply ?
> - _("Applying autostash resulted in conflicts.") :
> - _("Autostash exists; creating a new stash entry."));
> + " \"git stash drop\" at any time.\n"));
> }
This looks good now
> diff --git a/t/t7201-co.sh b/t/t7201-co.sh
> index 9bcf7c0b40..b3293ead8d 100755
> --- a/t/t7201-co.sh
> +++ b/t/t7201-co.sh
> @@ -102,7 +102,7 @@ test_expect_success 'checkout -m with dirty tree' '
>
> test "$(git symbolic-ref HEAD)" = "refs/heads/side" &&
>
> - printf "M\t%s\n" one >expect.messages &&
> + printf "The following paths have local changes:\nM\t%s\n" one >expect.messages &&
To create a multi-line file it is clearer to use
cat >expect.messages <<-\EOF &&
The following paths have local changes:
M one
EOF
> test_cmp expect.messages messages &&
>
> fill "M one" "A three" "D two" >expect.main &&
> @@ -210,6 +210,65 @@ test_expect_success 'checkout --merge --conflict=diff3 <branch>' '
> test_cmp expect two
> '
>
> +test_expect_success 'checkout -m with mixed staged and unstaged changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 0 x y z >same &&
> + git add same &&
> + fill 1 2 3 4 5 6 7 >one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep "Applied autostash" actual &&
> + fill 0 x y z >expect &&
> + test_cmp expect same &&
> + fill 1 2 3 4 5 6 7 >expect &&
> + test_cmp expect one
> +'
> +
> +test_expect_success 'checkout -m creates a recoverable stash on conflict' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + test_must_fail git checkout side 2>stderr &&
> + test_grep "Your local changes" stderr &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep "resulted in conflicts" actual &&
> + test_grep "git stash drop" actual &&
> + test_grep "git stash pop" actual &&
> + test_grep "The following paths have local changes" actual &&
> + git show --format=%B --diff-merges=1 refs/stash >actual &&
I've realized since I suggested this that we should be checking the
reflog message as well since that's what's shown by "git stash list" so
we need to run
git log -p -1 --format="%gs%n%B" -g --diff-merges=1 refs/stash >actual
> + sed /^index/d actual >actual.trimmed &&
> + cat >expect <<-EOF &&
and add
autostash while switching to ${SQ}side${SQ}
> + On main: autostash while switching to ${SQ}side${SQ}
> +
> + diff --git a/one b/one
> + --- a/one
> + +++ b/one
> + @@ -3,6 +3,3 @@
> + 3
> + 4
> + 5
> + -6
> + -7
> + -8
> + EOF
> + test_cmp expect actual.trimmed &&
> + git stash drop &&
> + git reset --hard
> +'
> +
> +test_expect_success 'checkout -m which would overwrite untracked file' '
> + git checkout -f --detach main &&
> + test_commit another-file &&
> + git checkout HEAD^ &&
> + >another-file.t &&
> + fill 1 2 3 4 5 >one &&
> + test_must_fail git checkout -m @{-1} 2>err &&
> + test_grep "would be overwritten by checkout" err &&
> + test_grep "another-file.t" err
Why the two calls to test_grep, rather than one? Anyway I've realized
since I suggested this test that we also need to check the message only
appears once to prevent a regression where merge_working_tree() calls
unpack_trees() without setting "quiet" the first time it is called. We
can do that by writing an expect file and calling test_cmp(), or by
using "test_line_count = 1 err"
Hopefully the next re-roll with be the final one
Thanks
Phillip
> +'
> +
> test_expect_success 'switch to another branch while carrying a deletion' '
> git checkout -f main &&
> git reset --hard &&
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 9838094b66..f877d9a433 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -914,7 +914,8 @@ test_expect_success 'merge with conflicted --autostash changes' '
> git diff >expect &&
> test_when_finished "test_might_fail git stash drop" &&
> git merge --autostash c3 2>err &&
> - test_grep "Applying autostash resulted in conflicts." err &&
> + test_grep "applying them" err &&
> + test_grep "resulted in conflicts" err &&
> git show HEAD:file >merge-result &&
> test_cmp result.1-9 merge-result &&
> git stash show -p >actual &&
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index f043330f2a..5ee2b96d0a 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -325,6 +325,18 @@ int parse_conflict_style_name(const char *value)
> return -1;
> }
>
> +const char *conflict_style_name(int style)
> +{
> + switch (style) {
> + case XDL_MERGE_DIFF3:
> + return "diff3";
> + case XDL_MERGE_ZEALOUS_DIFF3:
> + return "zdiff3";
> + default:
> + return "merge";
> + }
> +}
> +
> int git_xmerge_style = -1;
>
> int git_xmerge_config(const char *var, const char *value,
> diff --git a/xdiff-interface.h b/xdiff-interface.h
> index fbc4ceec40..ce54e1c0e0 100644
> --- a/xdiff-interface.h
> +++ b/xdiff-interface.h
> @@ -55,6 +55,7 @@ void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line, int cflags);
> void xdiff_clear_find_func(xdemitconf_t *xecfg);
> struct config_context;
> int parse_conflict_style_name(const char *value);
> +const char *conflict_style_name(int style);
> int git_xmerge_config(const char *var, const char *value,
> const struct config_context *ctx, void *cb);
> extern int git_xmerge_style;
^ permalink raw reply [flat|nested] 69+ messages in thread* [PATCH] checkout: add --autostash option for branch switching
2026-04-28 9:35 [PATCH v15 5/5] checkout -m: autostash when switching branches Phillip Wood
@ 2026-04-28 18:08 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-28 18:08 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> This is looking good, there are just a few small issues. Hopefully the
> next iteration will be the last.
Thanks for the encouragement! 💪🏻
> s/would/will/
👍
> It is the changes in the files overlapping that causes the merge
> conflict, not the files overlapping
>
> When the `--merge` (`-m`) option is given and the local changes
> overlap with the changes in the branch we're switching to,
👍
> I'd drop this line and say instead "a message is printed"
👍
> This needs updating to match the new conflict advice.
👍
> If you've not done so already it would be well worth checking the
> generated git-checkout.html and the man page
Good catch, I generated it now and yes it didn't look correct. I dropped
that last section now.
> Don't we show the modified files as well now?
Good catch, very good idea to actually generate the man html file and
check.
> As this function only sets up the flags for unpack_trees() I think we
> could call this "quiet" or "show_errors"
Good point!
> We've added a function parameter for this option but then we ignore it
> unless "merge" and "old_commit" are true which is confusing. The reason
> we used to check those was to set "quiet" automatically but we can't do
> that now, so why not just use the value the call requested?
Good point! I attempted to change this, hopefully it doesn't break anything!
> This is an "out" parameter, so it would make sense to keep it at the end
> of the parameter list.
👍
> To create a multi-line file it is clearer to use
>
> cat >expect.messages <<-\EOF &&
> The following paths have local changes:
> M one
> EOF
👍
> I've realized since I suggested this that we should be checking the
> reflog message as well since that's what's shown by "git stash list" so
> we need to run
>
> git log -p -1 --format="%gs%n%B" -g --diff-merges=1 refs/stash >actual
>
> > + sed /^index/d actual >actual.trimmed &&
> > + cat >expect <<-EOF &&
>
> and add
>
>
> autostash while switching to ${SQ}side${SQ}
Make sense!
> Why the two calls to test_grep, rather than one? Anyway I've realized
> since I suggested this test that we also need to check the message only
> appears once to prevent a regression where merge_working_tree() calls
> unpack_trees() without setting "quiet" the first time it is called. We
> can do that by writing an expect file and calling test_cmp(), or by
> using "test_line_count = 1 err"
Excellent point. I went with test_cmp since it's multi-line output and
"test_line_count = 1" seemed to not work then.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v15 3/5] sequencer: teach autostash apply to take optional conflict marker labels
@ 2026-04-28 9:33 Phillip Wood
2026-04-28 15:21 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-28 9:33 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 24/04/2026 22:10, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Add label_ours, label_theirs, label_base, and stash_msg parameters to
> apply_autostash_ref() and the autostash apply machinery so callers can
> pass custom conflict marker labels through to
> "git stash apply --label-ours/--label-theirs/--label-base", as well as
> a custom stash message for "git stash store -m".
I said before that I was confused as to why we need to pass a message
when all we're doing is saving an existing stash and the stash already
has the message we want. As that didn't get any response I've had a more
detailed look. The message here is used in the reflog (which is what
"git stash list" shows) and it appears that the reason for passing a
message when storing the stash is because "git stash store" is not smart
enough to reuse the subject from the stash commit message by default. It
would be nice to improve that rather than having to pass a message here.
"git rebase --autostash" and "git merge --autostash" do not have the
luxury of calling "git stash store" from the same process as "git stash
create" and so to improve the autostash message for those commands we'd
need to generate it twice which seems like an unnecessary complication.
One problem with that approach in the context of this series is that the
stash commit message begins "On <branch we're switching from>: " rather
than "On <branch we're switching to>: " but that means this commit is
just hiding the fact that commit message is wrong when we create the stash.
It may well be that fixing all that turns out to be a lot of work as it
would mean modifying do_create_stash() to allow the branch name to be
overridden and modifying store_stash() to use the commit subject as the
reflog message in which case we should leave that for a future series.
Thanks
Phillip
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v15 1/5] stash: add --label-ours, --label-theirs, --label-base for apply
@ 2026-04-28 9:32 Phillip Wood
2026-04-28 15:16 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-28 9:32 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 24/04/2026 22:10, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Allow callers of "git stash apply" to pass custom labels for conflict
> markers instead of the default "Updated upstream" and "Stashed changes".
> Document the new options and add a test.
This all looks good, just one small comment below
> - o.branch1 = "Updated upstream";
> - o.branch2 = "Stashed changes";
> - o.ancestor = "Stash base";
> + o.branch1 = label_ours ? label_ours : "Updated upstream";
> + o.branch2 = label_theirs ? label_theirs : "Stashed changes";
> + o.ancestor = label_base ? label_base : "Stash base";
This uses the existing label which is sensible, but I wonder if "Stash
HEAD" would be a better choice as the merge base is always HEAD commit
that the stash is based on.
We can always change that later
Thanks
Phillip
>
> if (oideq(&info->b_tree, &c_tree))
> o.branch1 = "Version stash was based on";
> @@ -723,11 +725,18 @@ static int apply_stash(int argc, const char **argv, const char *prefix,
> int ret = -1;
> int quiet = 0;
> int index = use_index;
> + const char *label_ours = NULL, *label_theirs = NULL, *label_base = NULL;
> struct stash_info info = STASH_INFO_INIT;
> struct option options[] = {
> OPT__QUIET(&quiet, N_("be quiet, only report errors")),
> OPT_BOOL(0, "index", &index,
> N_("attempt to recreate the index")),
> + OPT_STRING(0, "label-ours", &label_ours, N_("label"),
> + N_("label for the upstream side in conflict markers")),
> + OPT_STRING(0, "label-theirs", &label_theirs, N_("label"),
> + N_("label for the stashed side in conflict markers")),
> + OPT_STRING(0, "label-base", &label_base, N_("label"),
> + N_("label for the base in diff3 conflict markers")),
> OPT_END()
> };
>
> @@ -737,7 +746,8 @@ static int apply_stash(int argc, const char **argv, const char *prefix,
> if (get_stash_info(&info, argc, argv))
> goto cleanup;
>
> - ret = do_apply_stash(prefix, &info, index, quiet);
> + ret = do_apply_stash(prefix, &info, index, quiet,
> + label_ours, label_theirs, label_base);
> cleanup:
> free_stash_info(&info);
> return ret;
> @@ -836,7 +846,8 @@ static int pop_stash(int argc, const char **argv, const char *prefix,
> if (get_stash_info_assert(&info, argc, argv))
> goto cleanup;
>
> - if ((ret = do_apply_stash(prefix, &info, index, quiet)))
> + if ((ret = do_apply_stash(prefix, &info, index, quiet,
> + NULL, NULL, NULL)))
> printf_ln(_("The stash entry is kept in case "
> "you need it again."));
> else
> @@ -877,7 +888,8 @@ static int branch_stash(int argc, const char **argv, const char *prefix,
> strvec_push(&cp.args, oid_to_hex(&info.b_commit));
> ret = run_command(&cp);
> if (!ret)
> - ret = do_apply_stash(prefix, &info, 1, 0);
> + ret = do_apply_stash(prefix, &info, 1, 0,
> + NULL, NULL, NULL);
> if (!ret && info.is_stash_ref)
> ret = do_drop_stash(&info, 0);
>
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 70879941c2..bdaad22e1f 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -56,6 +56,7 @@ setup_stash() {
> git add other-file &&
> test_tick &&
> git commit -m initial &&
> + git tag initial &&
> echo 2 >file &&
> git add file &&
> echo 3 >file &&
> @@ -1790,4 +1791,27 @@ test_expect_success 'stash.index=false overridden by --index' '
> test_cmp expect file
> '
>
> +test_expect_success 'apply with custom conflict labels' '
> + git reset --hard initial &&
> + test_commit label-base conflict-file base-content &&
> + echo stashed >conflict-file &&
> + git stash push -m "stashed" &&
> + test_commit label-upstream conflict-file upstream-content &&
> + test_must_fail git -c merge.conflictStyle=diff3 stash apply --label-ours=UP --label-theirs=STASH &&
> + test_grep "^<<<<<<< UP" conflict-file &&
> + test_grep "^||||||| Stash base" conflict-file &&
> + test_grep "^>>>>>>> STASH" conflict-file
> +'
> +
> +test_expect_success 'apply with empty conflict labels' '
> + git reset --hard initial &&
> + test_commit empty-label-base conflict-file base-content &&
> + echo stashed >conflict-file &&
> + git stash push -m "stashed" &&
> + test_commit empty-label-upstream conflict-file upstream-content &&
> + test_must_fail git stash apply --label-ours= --label-theirs= &&
> + test_grep "^<<<<<<<$" conflict-file &&
> + test_grep "^>>>>>>>$" conflict-file
> +'
> +
> test_done
> diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
> index 29dad98c49..659ad4ec97 100644
> --- a/xdiff/xmerge.c
> +++ b/xdiff/xmerge.c
> @@ -199,9 +199,9 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char *name1,
> int size, int i, int style,
> xdmerge_t *m, char *dest, int marker_size)
> {
> - int marker1_size = (name1 ? strlen(name1) + 1 : 0);
> - int marker2_size = (name2 ? strlen(name2) + 1 : 0);
> - int marker3_size = (name3 ? strlen(name3) + 1 : 0);
> + int marker1_size = (name1 && *name1 ? strlen(name1) + 1 : 0);
> + int marker2_size = (name2 && *name2 ? strlen(name2) + 1 : 0);
> + int marker3_size = (name3 && *name3 ? strlen(name3) + 1 : 0);
> int needs_cr = is_cr_needed(xe1, xe2, m);
>
> if (marker_size <= 0)
^ permalink raw reply [flat|nested] 69+ messages in thread* [PATCH] checkout: add --autostash option for branch switching
2026-04-28 9:32 [PATCH v15 1/5] stash: add --label-ours, --label-theirs, --label-base for apply Phillip Wood
@ 2026-04-28 15:16 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-28 15:16 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> This uses the existing label which is sensible, but I wonder if "Stash
> HEAD" would be a better choice as the merge base is always HEAD commit
> that the stash is based on.
>
> We can always change that later
Yeah, seems better to do later.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH v14 0/5] checkout: 'autostash' for branch switching
@ 2026-04-15 16:24 Harald Nordgren via GitGitGadget
2026-04-21 7:53 ` [PATCH] checkout: add --autostash option " Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren via GitGitGadget @ 2026-04-15 16:24 UTC (permalink / raw)
To: git; +Cc: Phillip Wood, Chris Torek, Jeff King, Harald Nordgren
Simplifying the tests in t/t3903-stash.sh according to Phillip Wood's
comment. I believe everything sound be fixed now or responded to.
Also rebasing against upstream.
Harald Nordgren (5):
stash: add --label-ours, --label-theirs, --label-base for apply
sequencer: allow create_autostash to run silently
sequencer: teach autostash apply to take optional conflict marker
labels
checkout: rollback lock on early returns in merge_working_tree
checkout -m: autostash when switching branches
Documentation/git-checkout.adoc | 58 ++++-----
Documentation/git-stash.adoc | 11 +-
Documentation/git-switch.adoc | 33 ++---
builtin/checkout.c | 149 +++++++++++------------
builtin/commit.c | 3 +-
builtin/merge.c | 15 ++-
builtin/stash.c | 28 +++--
sequencer.c | 73 ++++++++---
sequencer.h | 7 +-
t/t3420-rebase-autostash.sh | 24 +++-
t/t3903-stash.sh | 24 ++++
t/t7201-co.sh | 208 ++++++++++++++++++++++++++++++++
t/t7600-merge.sh | 2 +-
xdiff-interface.c | 12 ++
xdiff-interface.h | 1 +
xdiff/xmerge.c | 6 +-
16 files changed, 483 insertions(+), 171 deletions(-)
base-commit: 9f223ef1c026d91c7ac68cc0211bde255dda6199
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2234%2FHaraldNordgren%2Fcheckout_autostash-v14
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2234/HaraldNordgren/checkout_autostash-v14
Pull-Request: https://github.com/git/git/pull/2234
Range-diff vs v13:
1: 43bfdf2136 ! 1: e18c25599a stash: add --label-ours, --label-theirs, --label-base for apply
@@ builtin/stash.c: static int branch_stash(int argc, const char **argv, const char
## t/t3903-stash.sh ##
-@@ t/t3903-stash.sh: test_expect_success 'restore untracked files even when we hit conflicts' '
- )
+@@ t/t3903-stash.sh: setup_stash() {
+ git add other-file &&
+ test_tick &&
+ git commit -m initial &&
++ git tag initial &&
+ echo 2 >file &&
+ git add file &&
+ echo 3 >file &&
+@@ t/t3903-stash.sh: test_expect_success 'stash.index=false overridden by --index' '
+ test_cmp expect file
'
+test_expect_success 'apply with custom conflict labels' '
-+ test_when_finished "git reset --hard && git stash drop" &&
-+ git reset --hard &&
++ git reset --hard initial &&
+ test_commit label-base conflict-file base-content &&
+ echo stashed >conflict-file &&
+ git stash push -m "stashed" &&
@@ t/t3903-stash.sh: test_expect_success 'restore untracked files even when we hit
+'
+
+test_expect_success 'apply with empty conflict labels' '
-+ test_when_finished "git reset --hard && git stash drop" &&
-+ git reset --hard &&
++ git reset --hard initial &&
+ test_commit empty-label-base conflict-file base-content &&
+ echo stashed >conflict-file &&
+ git stash push -m "stashed" &&
@@ t/t3903-stash.sh: test_expect_success 'restore untracked files even when we hit
+ test_grep "^>>>>>>>$" conflict-file
+'
+
- test_expect_success 'stash create reports a locked index' '
- test_when_finished "rm -rf repo" &&
- git init repo &&
+ test_done
## xdiff/xmerge.c ##
@@ xdiff/xmerge.c: static int fill_conflict_hunk(xdfenv_t *xe1, const char *name1,
2: 7f3c32f5e9 = 2: ce29b10264 sequencer: allow create_autostash to run silently
3: b279d1dac8 = 3: 73051d1762 sequencer: teach autostash apply to take optional conflict marker labels
4: 04869314ec = 4: 191058d8e3 checkout: rollback lock on early returns in merge_working_tree
5: 4b3c6025ac = 5: 86f33df1eb checkout -m: autostash when switching branches
--
gitgitgadget
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v12 0/4] checkout: 'autostash' for branch switching
@ 2026-04-14 15:56 Junio C Hamano
2026-04-14 20:16 ` [PATCH] checkout: add --autostash option " Harald Nordgren
2026-04-16 10:05 ` Harald Nordgren
0 siblings, 2 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-04-14 15:56 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget
Cc: git, Phillip Wood, Chris Torek, Jeff King, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Harald Nordgren (4):
> stash: add --label-ours, --label-theirs, --label-base for apply
> sequencer: allow create_autostash to run silently
> sequencer: teach autostash apply to take optional conflict marker
> labels
> checkout: -m (--merge) uses autostash when switching branches
>
> Documentation/git-checkout.adoc | 58 ++++-----
> Documentation/git-stash.adoc | 11 +-
> Documentation/git-switch.adoc | 33 ++---
> builtin/checkout.c | 147 ++++++++++------------
> builtin/stash.c | 32 +++--
> sequencer.c | 81 ++++++++++---
> sequencer.h | 6 +
> t/t3420-rebase-autostash.sh | 24 +++-
> t/t3903-stash.sh | 29 +++++
> t/t7201-co.sh | 208 ++++++++++++++++++++++++++++++++
> t/t7600-merge.sh | 2 +-
> xdiff-interface.c | 12 ++
> xdiff-interface.h | 1 +
> xdiff/xmerge.c | 6 +-
> 14 files changed, 491 insertions(+), 159 deletions(-)
I am not taking v11 and v12 today, as v10 is already in 'next', but
for future reference, I have to say that this cover letter is not
very helpful.
It shows 350+ lines of range-diff to show mostly irrelevant noise,
when the true difference between v11 and v12 is only that two helper
functions create_autostash_ref_silent{,_with_msg}() are merged into
one create_autostash_ref_with_msg_silent() helper function.
It is much easier to read that read from the diff between the
results of applying v11 and v12 on the same base commit, which is a
mere 55 lines (shown at the end).
I would not expect you to teach GGG to produce a better range-diff
or add an option to instead show an interdiff, but doesn't GGG
already have a way to add some human-written comment, e.g.,
Changes since v11:
Two helper functions create_autostash_ref_silent{,_with_msg}()
are merged into one create_autostash_ref_with_msg_silent().
to the cover letter? Such a comment, even a very short one like I
showed above, would be a lot more effective way to help human
readers to decide what is the point of this iteration is, especially
when you are sending v11 and v12 almost back-to-back, and to decide
if it is easier to understand to read both or if v11 can be skipped
and reading v12 alone (with the understanding of the difference
explained in the comment) should be enough to tell if v12 is an
improvement over v11 or not.
https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md#patch-submissions
says that
The description of the Pull Request will be used as cover
letter, ...
so perhaps your pull-request comment should have something more than
just the list of CC: recipients?
Thanks.
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2adfefa085..a7a93e1c6b 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1155,9 +1155,9 @@ static int switch_branches(const struct checkout_opts *opts,
strbuf_addf(&autostash_msg,
"autostash while switching to '%s'",
new_branch_info->name);
- create_autostash_ref_silent_with_msg(the_repository,
- "CHECKOUT_AUTOSTASH_HEAD",
- autostash_msg.buf);
+ create_autostash_ref_with_msg_silent(the_repository,
+ "CHECKOUT_AUTOSTASH_HEAD",
+ autostash_msg.buf);
created_autostash = 1;
ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
}
diff --git a/sequencer.c b/sequencer.c
index febdb5b20a..b78a8ff092 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -4726,14 +4726,8 @@ void create_autostash_ref(struct repository *r, const char *refname)
create_autostash_internal(r, NULL, refname, NULL, false);
}
-void create_autostash_ref_silent(struct repository *r, const char *refname)
-{
- create_autostash_internal(r, NULL, refname, NULL, true);
-}
-
-void create_autostash_ref_silent_with_msg(struct repository *r,
- const char *refname,
- const char *message)
+void create_autostash_ref_with_msg_silent(struct repository *r, const char *refname,
+ const char *message)
{
create_autostash_internal(r, NULL, refname, message, true);
}
diff --git a/sequencer.h b/sequencer.h
index 67de755053..b0c891d3b6 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -230,10 +230,8 @@ void commit_post_rewrite(struct repository *r,
void create_autostash(struct repository *r, const char *path);
void create_autostash_ref(struct repository *r, const char *refname);
-void create_autostash_ref_silent(struct repository *r, const char *refname);
-void create_autostash_ref_silent_with_msg(struct repository *r,
- const char *refname,
- const char *message);
+void create_autostash_ref_with_msg_silent(struct repository *r, const char *refname,
+ const char *message);
int save_autostash(const char *path);
int save_autostash_ref(struct repository *r, const char *refname);
int apply_autostash(const char *path);
> base-commit: 9e8f4e9c04e3efa494e78b710e0c5f6cc77a0a5e
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2234%2FHaraldNordgren%2Fcheckout_autostash-v12
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2234/HaraldNordgren/checkout_autostash-v12
> Pull-Request: https://github.com/git/git/pull/2234
>
> Range-diff vs v11:
>
> 1: 9ab5431b47 = 1: 9ab5431b47 stash: add --label-ours, --label-theirs, --label-base for apply
> 2: e7f8328e3c ! 2: e11a622bdf sequencer: allow create_autostash to run silently
> @@ sequencer.c: static enum todo_command peek_command(struct todo_list *todo_list,
> const char *path,
> - const char *refname)
> + const char *refname,
> ++ const char *message,
> + bool silent)
> {
> struct strbuf buf = STRBUF_INIT;
> struct lock_file lock_file = LOCK_INIT;
> +@@ sequencer.c: static void create_autostash_internal(struct repository *r,
> + struct object_id oid;
> +
> + strvec_pushl(&stash.args,
> +- "stash", "create", "autostash", NULL);
> ++ "stash", "create",
> ++ message ? message : "autostash", NULL);
> + stash.git_cmd = 1;
> + stash.no_stdin = 1;
> + strbuf_reset(&buf);
> @@ sequencer.c: static void create_autostash_internal(struct repository *r,
> &oid, null_oid(the_hash_algo), 0, UPDATE_REFS_DIE_ON_ERR);
> }
> @@ sequencer.c: static void create_autostash_internal(struct repository *r,
> void create_autostash(struct repository *r, const char *path)
> {
> - create_autostash_internal(r, path, NULL);
> -+ create_autostash_internal(r, path, NULL, false);
> ++ create_autostash_internal(r, path, NULL, NULL, false);
> }
>
> void create_autostash_ref(struct repository *r, const char *refname)
> {
> - create_autostash_internal(r, NULL, refname);
> -+ create_autostash_internal(r, NULL, refname, false);
> ++ create_autostash_internal(r, NULL, refname, NULL, false);
> +}
> +
> -+void create_autostash_ref_silent(struct repository *r, const char *refname)
> ++void create_autostash_ref_with_msg_silent(struct repository *r, const char *refname,
> ++ const char *message)
> +{
> -+ create_autostash_internal(r, NULL, refname, true);
> ++ create_autostash_internal(r, NULL, refname, message, true);
> }
>
> static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
> @@ sequencer.h: void commit_post_rewrite(struct repository *r,
>
> void create_autostash(struct repository *r, const char *path);
> void create_autostash_ref(struct repository *r, const char *refname);
> -+void create_autostash_ref_silent(struct repository *r, const char *refname);
> ++void create_autostash_ref_with_msg_silent(struct repository *r, const char *refname,
> ++ const char *message);
> int save_autostash(const char *path);
> int save_autostash_ref(struct repository *r, const char *refname);
> int apply_autostash(const char *path);
> 3: 3242fd3261 ! 3: 4593745e90 sequencer: teach autostash apply to take optional conflict marker labels
> @@ Commit message
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
>
> ## sequencer.c ##
> -@@ sequencer.c: void create_autostash_ref_silent(struct repository *r, const char *refname)
> - create_autostash_internal(r, NULL, refname, true);
> +@@ sequencer.c: void create_autostash_ref_with_msg_silent(struct repository *r, const char *refn
> + create_autostash_internal(r, NULL, refname, message, true);
> }
>
> -static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
> +static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply,
> + const char *label_ours, const char *label_theirs,
> -+ const char *label_base)
> ++ const char *label_base,
> ++ const char *stash_msg)
> {
> struct child_process child = CHILD_PROCESS_INIT;
> int ret = 0;
> @@ sequencer.c: static int apply_save_autostash_oid(const char *stash_oid, int atte
> strvec_push(&child.args, stash_oid);
> ret = run_command(&child);
> }
> +@@ sequencer.c: static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
> + strvec_push(&store.args, "stash");
> + strvec_push(&store.args, "store");
> + strvec_push(&store.args, "-m");
> +- strvec_push(&store.args, "autostash");
> ++ strvec_push(&store.args, stash_msg ? stash_msg : "autostash");
> + strvec_push(&store.args, "-q");
> + strvec_push(&store.args, stash_oid);
> + if (run_command(&store))
> @@ sequencer.c: static int apply_save_autostash(const char *path, int attempt_apply)
> }
> strbuf_trim(&stash_oid);
>
> - ret = apply_save_autostash_oid(stash_oid.buf, attempt_apply);
> + ret = apply_save_autostash_oid(stash_oid.buf, attempt_apply,
> -+ NULL, NULL, NULL);
> ++ NULL, NULL, NULL, NULL);
>
> unlink(path);
> strbuf_release(&stash_oid);
> @@ sequencer.c: int apply_autostash(const char *path)
> int apply_autostash_oid(const char *stash_oid)
> {
> - return apply_save_autostash_oid(stash_oid, 1);
> -+ return apply_save_autostash_oid(stash_oid, 1, NULL, NULL, NULL);
> ++ return apply_save_autostash_oid(stash_oid, 1, NULL, NULL, NULL, NULL);
> }
>
> static int apply_save_autostash_ref(struct repository *r, const char *refname,
> - int attempt_apply)
> + int attempt_apply,
> + const char *label_ours, const char *label_theirs,
> -+ const char *label_base)
> ++ const char *label_base,
> ++ const char *stash_msg)
> {
> struct object_id stash_oid;
> char stash_oid_hex[GIT_MAX_HEXSZ + 1];
> @@ sequencer.c: static int apply_save_autostash_ref(struct repository *r, const cha
> oid_to_hex_r(stash_oid_hex, &stash_oid);
> - ret = apply_save_autostash_oid(stash_oid_hex, attempt_apply);
> + ret = apply_save_autostash_oid(stash_oid_hex, attempt_apply,
> -+ label_ours, label_theirs, label_base);
> ++ label_ours, label_theirs, label_base,
> ++ stash_msg);
>
> refs_delete_ref(get_main_ref_store(r), "", refname,
> &stash_oid, REF_NO_DEREF);
> @@ sequencer.c: static int apply_save_autostash_ref(struct repository *r, const cha
> int save_autostash_ref(struct repository *r, const char *refname)
> {
> - return apply_save_autostash_ref(r, refname, 0);
> -+ return apply_save_autostash_ref(r, refname, 0, NULL, NULL, NULL);
> ++ return apply_save_autostash_ref(r, refname, 0,
> ++ NULL, NULL, NULL, NULL);
> }
>
> int apply_autostash_ref(struct repository *r, const char *refname)
> {
> - return apply_save_autostash_ref(r, refname, 1);
> -+ return apply_save_autostash_ref(r, refname, 1, NULL, NULL, NULL);
> ++ return apply_save_autostash_ref(r, refname, 1,
> ++ NULL, NULL, NULL, NULL);
> +}
> +
> +int apply_autostash_ref_with_labels(struct repository *r, const char *refname,
> + const char *label_ours, const char *label_theirs,
> -+ const char *label_base)
> ++ const char *label_base,
> ++ const char *stash_msg)
> +{
> + return apply_save_autostash_ref(r, refname, 1,
> -+ label_ours, label_theirs, label_base);
> ++ label_ours, label_theirs, label_base,
> ++ stash_msg);
> }
>
> static int checkout_onto(struct repository *r, struct replay_opts *opts,
> @@ sequencer.h: int save_autostash_ref(struct repository *r, const char *refname);
> int apply_autostash_ref(struct repository *r, const char *refname);
> +int apply_autostash_ref_with_labels(struct repository *r, const char *refname,
> + const char *label_ours, const char *label_theirs,
> -+ const char *label_base);
> ++ const char *label_base,
> ++ const char *stash_msg);
>
> #define SUMMARY_INITIAL_COMMIT (1 << 0)
> #define SUMMARY_SHOW_AUTHOR_DATE (1 << 1)
> 4: 97a5d87c81 ! 4: 911e520431 checkout: -m (--merge) uses autostash when switching branches
> @@ builtin/checkout.c: static int switch_branches(const struct checkout_opts *opts,
> + strbuf_addf(&autostash_msg,
> + "autostash while switching to '%s'",
> + new_branch_info->name);
> -+ create_autostash_ref_silent_with_msg(the_repository,
> -+ "CHECKOUT_AUTOSTASH_HEAD",
> -+ autostash_msg.buf);
> ++ create_autostash_ref_with_msg_silent(the_repository,
> ++ "CHECKOUT_AUTOSTASH_HEAD",
> ++ autostash_msg.buf);
> + created_autostash = 1;
> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> + }
> @@ builtin/checkout.c: static int switch_branches(const struct checkout_opts *opts,
> }
>
> ## sequencer.c ##
> -@@ sequencer.c: static enum todo_command peek_command(struct todo_list *todo_list, int offset)
> - static void create_autostash_internal(struct repository *r,
> - const char *path,
> - const char *refname,
> -+ const char *message,
> - bool silent)
> - {
> - struct strbuf buf = STRBUF_INIT;
> -@@ sequencer.c: static void create_autostash_internal(struct repository *r,
> - struct object_id oid;
> -
> - strvec_pushl(&stash.args,
> -- "stash", "create", "autostash", NULL);
> -+ "stash", "create",
> -+ message ? message : "autostash", NULL);
> - stash.git_cmd = 1;
> - stash.no_stdin = 1;
> - strbuf_reset(&buf);
> -@@ sequencer.c: static void create_autostash_internal(struct repository *r,
> -
> - void create_autostash(struct repository *r, const char *path)
> - {
> -- create_autostash_internal(r, path, NULL, false);
> -+ create_autostash_internal(r, path, NULL, NULL, false);
> - }
> -
> - void create_autostash_ref(struct repository *r, const char *refname)
> - {
> -- create_autostash_internal(r, NULL, refname, false);
> -+ create_autostash_internal(r, NULL, refname, NULL, false);
> - }
> -
> - void create_autostash_ref_silent(struct repository *r, const char *refname)
> - {
> -- create_autostash_internal(r, NULL, refname, true);
> -+ create_autostash_internal(r, NULL, refname, NULL, true);
> -+}
> -+
> -+void create_autostash_ref_silent_with_msg(struct repository *r,
> -+ const char *refname,
> -+ const char *message)
> -+{
> -+ create_autostash_internal(r, NULL, refname, message, true);
> - }
> -
> - static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply,
> - const char *label_ours, const char *label_theirs,
> -- const char *label_base)
> -+ const char *label_base,
> -+ const char *stash_msg)
> - {
> - struct child_process child = CHILD_PROCESS_INIT;
> - int ret = 0;
> @@ sequencer.c: static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply,
> - strvec_push(&store.args, "stash");
> - strvec_push(&store.args, "store");
> - strvec_push(&store.args, "-m");
> -- strvec_push(&store.args, "autostash");
> -+ strvec_push(&store.args, stash_msg ? stash_msg : "autostash");
> - strvec_push(&store.args, "-q");
> strvec_push(&store.args, stash_oid);
> if (run_command(&store))
> ret = error(_("cannot store %s"), stash_oid);
> @@ sequencer.c: static int apply_save_autostash_oid(const char *stash_oid, int atte
> }
>
> return ret;
> -@@ sequencer.c: static int apply_save_autostash(const char *path, int attempt_apply)
> - strbuf_trim(&stash_oid);
> -
> - ret = apply_save_autostash_oid(stash_oid.buf, attempt_apply,
> -- NULL, NULL, NULL);
> -+ NULL, NULL, NULL, NULL);
> -
> - unlink(path);
> - strbuf_release(&stash_oid);
> -@@ sequencer.c: int apply_autostash(const char *path)
> -
> - int apply_autostash_oid(const char *stash_oid)
> - {
> -- return apply_save_autostash_oid(stash_oid, 1, NULL, NULL, NULL);
> -+ return apply_save_autostash_oid(stash_oid, 1, NULL, NULL, NULL, NULL);
> - }
> -
> - static int apply_save_autostash_ref(struct repository *r, const char *refname,
> - int attempt_apply,
> - const char *label_ours, const char *label_theirs,
> -- const char *label_base)
> -+ const char *label_base,
> -+ const char *stash_msg)
> - {
> - struct object_id stash_oid;
> - char stash_oid_hex[GIT_MAX_HEXSZ + 1];
> -@@ sequencer.c: static int apply_save_autostash_ref(struct repository *r, const char *refname,
> -
> - oid_to_hex_r(stash_oid_hex, &stash_oid);
> - ret = apply_save_autostash_oid(stash_oid_hex, attempt_apply,
> -- label_ours, label_theirs, label_base);
> -+ label_ours, label_theirs, label_base,
> -+ stash_msg);
> -
> - refs_delete_ref(get_main_ref_store(r), "", refname,
> - &stash_oid, REF_NO_DEREF);
> -@@ sequencer.c: static int apply_save_autostash_ref(struct repository *r, const char *refname,
> -
> - int save_autostash_ref(struct repository *r, const char *refname)
> - {
> -- return apply_save_autostash_ref(r, refname, 0, NULL, NULL, NULL);
> -+ return apply_save_autostash_ref(r, refname, 0,
> -+ NULL, NULL, NULL, NULL);
> - }
> -
> - int apply_autostash_ref(struct repository *r, const char *refname)
> - {
> -- return apply_save_autostash_ref(r, refname, 1, NULL, NULL, NULL);
> -+ return apply_save_autostash_ref(r, refname, 1,
> -+ NULL, NULL, NULL, NULL);
> - }
> -
> - int apply_autostash_ref_with_labels(struct repository *r, const char *refname,
> - const char *label_ours, const char *label_theirs,
> -- const char *label_base)
> -+ const char *label_base,
> -+ const char *stash_msg)
> - {
> - return apply_save_autostash_ref(r, refname, 1,
> -- label_ours, label_theirs, label_base);
> -+ label_ours, label_theirs, label_base,
> -+ stash_msg);
> - }
> -
> - static int checkout_onto(struct repository *r, struct replay_opts *opts,
> -
> - ## sequencer.h ##
> -@@ sequencer.h: void commit_post_rewrite(struct repository *r,
> - void create_autostash(struct repository *r, const char *path);
> - void create_autostash_ref(struct repository *r, const char *refname);
> - void create_autostash_ref_silent(struct repository *r, const char *refname);
> -+void create_autostash_ref_silent_with_msg(struct repository *r,
> -+ const char *refname,
> -+ const char *message);
> - int save_autostash(const char *path);
> - int save_autostash_ref(struct repository *r, const char *refname);
> - int apply_autostash(const char *path);
> -@@ sequencer.h: int apply_autostash_oid(const char *stash_oid);
> - int apply_autostash_ref(struct repository *r, const char *refname);
> - int apply_autostash_ref_with_labels(struct repository *r, const char *refname,
> - const char *label_ours, const char *label_theirs,
> -- const char *label_base);
> -+ const char *label_base,
> -+ const char *stash_msg);
> -
> - #define SUMMARY_INITIAL_COMMIT (1 << 0)
> - #define SUMMARY_SHOW_AUTHOR_DATE (1 << 1)
>
> ## t/t3420-rebase-autostash.sh ##
> @@ t/t3420-rebase-autostash.sh: create_expected_failure_apply () {
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 15:56 [PATCH v12 0/4] checkout: 'autostash' " Junio C Hamano
@ 2026-04-14 20:16 ` Harald Nordgren
2026-04-14 20:56 ` Junio C Hamano
2026-04-16 10:05 ` Harald Nordgren
1 sibling, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 20:16 UTC (permalink / raw)
To: gitster
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood123
> The description of the Pull Request will be used as cover
> letter, ...
>
> so perhaps your pull-request comment should have something more than
> just the list of CC: recipients?
I'll give it a try!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 20:16 ` [PATCH] checkout: add --autostash option " Harald Nordgren
@ 2026-04-14 20:56 ` Junio C Hamano
0 siblings, 0 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-04-14 20:56 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood123
Harald Nordgren <haraldnordgren@gmail.com> writes:
>> The description of the Pull Request will be used as cover
>> letter, ...
>>
>> so perhaps your pull-request comment should have something more than
>> just the list of CC: recipients?
>
> I'll give it a try!
;-)
I find that many topics by Patrick Steinhardt and Jeff King with
multiple iterations often come with good cover letters that outline
updates between iterations.
Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 15:56 [PATCH v12 0/4] checkout: 'autostash' " Junio C Hamano
2026-04-14 20:16 ` [PATCH] checkout: add --autostash option " Harald Nordgren
@ 2026-04-16 10:05 ` Harald Nordgren
2026-04-16 14:45 ` Junio C Hamano
1 sibling, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-16 10:05 UTC (permalink / raw)
To: gitster
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood123
> It shows 350+ lines of range-diff to show mostly irrelevant noise,
> when the true difference between v11 and v12 is only that two helper
> functions create_autostash_ref_silent{,_with_msg}() are merged into
> one create_autostash_ref_with_msg_silent() helper function.
>
> It is much easier to read that read from the diff between the
> results of applying v11 and v12 on the same base commit, which is a
> mere 55 lines (shown at the end).
>
> I would not expect you to teach GGG to produce a better range-diff
> or add an option to instead show an interdiff, but doesn't GGG
> already have a way to add some human-written comment
I will work on my cover letters, that's a very fair point.
I do think there is some possibility to handle this via maybe a new
option 'git range-diff --rebase', or directly via GitGitGadget. This would
automatically create a diff with only the files actually changed, which
saves both author's and reviewer's time.
Perhaps this: https://github.com/gitgitgadget/gitgitgadget/pull/2212
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-16 10:05 ` Harald Nordgren
@ 2026-04-16 14:45 ` Junio C Hamano
2026-04-16 17:53 ` Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-16 14:45 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood123
Harald Nordgren <haraldnordgren@gmail.com> writes:
> I do think there is some possibility to handle this via maybe a new
> option 'git range-diff --rebase', or directly via GitGitGadget. This would
> automatically create a diff with only the files actually changed, which
> saves both author's and reviewer's time.
I am not sure. Have you actually tried to apply two iterations (I
think it was between v11 and v12 but please double check) on the
same base and ran range-diff, and compared the result with what I
complained about? You added one helper in the new iteration, that
replaces two helpers you added to the old iteration, and the part of
the range-diff that I called "less interesting" noise were the
change to the callers to the original two helpers to make them call
the unified helper, inevitably with different arguments. I am not
sure a mechanical textual comparison tool can tell them from the
more interesting change that shows that two old helpers did not get
added and instead one new unified helper got added. I do not expect
this to change if two versions compared were built on the same base.
And that is why I kept saying that the cover letter needs some
comments written by the author to guide readers which parts of the
changes are notable.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-16 14:45 ` Junio C Hamano
@ 2026-04-16 17:53 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-16 17:53 UTC (permalink / raw)
To: gitster
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood123
> I am not sure. Have you actually tried to apply two iterations (I
> think it was between v11 and v12 but please double check) on the
> same base and ran range-diff, and compared the result with what I
> complained about?
Fair enough, it's not great!
> And that is why I kept saying that the cover letter needs some
> comments written by the author to guide readers which parts of the
> changes are notable.
I hear you loud and clear! Next patch will have a better cover letter
if or when it comes!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v12 4/4] checkout: -m (--merge) uses autostash when switching branches
@ 2026-04-14 14:07 Phillip Wood
2026-04-14 20:06 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
` (2 more replies)
0 siblings, 3 replies; 69+ messages in thread
From: Phillip Wood @ 2026-04-14 14:07 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
For the subject line I think
checkout -m: autostash when switching branches
would be more in keeping with our usual style.
On 14/04/2026 13:59, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When switching branches with "git checkout -m", local modifications
> can block the switch.
Really? Isn't the point of "checkout -m" to merge the local
modifications into the branch that's being checked out?
> Teach the -m flow to create a temporary stash
> before switching and reapply it after. On success, only "Applied
> autostash." is shown.
and a diff of the local changes?
> If reapplying causes conflicts, the stash is
> kept and the user is told they can resolve and run "git stash drop",
> or run "git reset --hard" and later "git stash pop" to recover their
> changes.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
I've skipped the docs as I'm short on time
> @@ -783,8 +783,10 @@ static int merge_working_tree(const struct checkout_opts *opts,
> struct tree *new_tree;
>
> repo_hold_locked_index(the_repository, &lock_file, LOCK_DIE_ON_ERROR);
> - if (repo_read_index_preload(the_repository, NULL, 0) < 0)
> + if (repo_read_index_preload(the_repository, NULL, 0) < 0) {
> + rollback_lock_file(&lock_file);
> return error(_("index file corrupt"));
> + }
>
> resolve_undo_clear_index(the_repository->index);
> if (opts->new_orphan_branch && opts->orphan_from_empty_tree) {
> @@ -797,14 +799,18 @@ static int merge_working_tree(const struct checkout_opts *opts,
> } else {
> new_tree = repo_get_commit_tree(the_repository,
> new_branch_info->commit);
> - if (!new_tree)
> + if (!new_tree) {
> + rollback_lock_file(&lock_file);
> return error(_("unable to read tree (%s)"),
> oid_to_hex(&new_branch_info->commit->object.oid));
> + }
> }
> if (opts->discard_changes) {
> ret = reset_tree(new_tree, opts, 1, writeout_error, new_branch_info);
> - if (ret)
> + if (ret) {
> + rollback_lock_file(&lock_file);
> return ret;
> + }
> } else {
> struct tree_desc trees[2];
> struct tree *tree;
> @@ -814,6 +820,7 @@ static int merge_working_tree(const struct checkout_opts *opts,
> refresh_index(the_repository->index, REFRESH_QUIET, NULL, NULL, NULL);
>
> if (unmerged_index(the_repository->index)) {
> + rollback_lock_file(&lock_file);
> error(_("you need to resolve your current index first"));
> return 1;
The changes up to here look like fixes for an existing bug and so would
be better in a separate patch.
Sometimes we return "1" and sometimes "-1" what does that signal to the
caller?
> }
> @@ -846,82 +853,8 @@ static int merge_working_tree(const struct checkout_opts *opts,
> ret = unpack_trees(2, trees, &topts);
> clear_unpack_trees_porcelain(&topts);
> if (ret == -1) {
> [lots of deletions]
> - if (ret)
> - return ret;
> + rollback_lock_file(&lock_file);
> + return 1;
> }
> }
>
> @@ -1166,6 +1099,10 @@ static int switch_branches(const struct checkout_opts *opts,
> struct object_id rev;
> int flag, writeout_error = 0;
> int do_merge = 1;
> + int created_autostash = 0;
This can be a bool
> + struct strbuf old_commit_shortname = STRBUF_INIT;
> + struct strbuf autostash_msg = STRBUF_INIT;
> + const char *stash_label_base = NULL;
>
> trace2_cmd_mode("branch");
>
> @@ -1203,10 +1140,37 @@ static int switch_branches(const struct checkout_opts *opts,
> do_merge = 0;
> }
>
> + if (old_branch_info.name)
> + stash_label_base = old_branch_info.name;
> + else if (old_branch_info.commit) {
> + strbuf_add_unique_abbrev(&old_commit_shortname,
> + &old_branch_info.commit->object.oid,
> + DEFAULT_ABBREV);
> + stash_label_base = old_commit_shortname.buf;
> + }
> +
> if (do_merge) {
> ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> + if (ret && opts->merge) {
As we saw above merge_working_tree() can return non-zero for a variety
of reasons. We only want to try stashing if the call to unpack_trees()
failed. Even then if you look at the list of errors in unpack-trees.h
you'll see that only a few of them relate to problems that can be solved
by stashing. The old code just tried merging whenever unpack_trees()
failed so it probably not so bad to do the same here but we should not
be stashing if merge_working_tree() returns before calling unpack_trees().
> + strbuf_addf(&autostash_msg,
> + "autostash while switching to '%s'",
> + new_branch_info->name);
> + create_autostash_ref_with_msg_silent(the_repository,
> + "CHECKOUT_AUTOSTASH_HEAD",
It's a shame we have to create a ref here. MERGE_AUTOSTASH exists so
that "git merge --continue" can apply the stash once the user has
resolved any merge conflicts. We don't have that problem here because
there is no user interaction and we could just hold onto the stash oid
in a variable.
> + autostash_msg.buf);
> + created_autostash = 1;
> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> + }
> if (ret) {
I'm confused by this - if we stash then don't we expect the call to
unpack_trees() in merge_working_tree() to succeed and therefore return
0? If opts->merge is false then we should not be trying to apply the
stash when merge_working_tree() fails.
> + apply_autostash_ref_with_labels(the_repository,
> + "CHECKOUT_AUTOSTASH_HEAD",
> + new_branch_info->name,
> + "local",
> + stash_label_base,
> + autostash_msg.len ? autostash_msg.buf : NULL);
Can we create an autostash without setting a message in autostash_msg?
> branch_info_release(&old_branch_info);
> + strbuf_release(&old_commit_shortname);
> + strbuf_release(&autostash_msg);
> return ret;
> }
> }
> @@ -1216,8 +1180,31 @@ static int switch_branches(const struct checkout_opts *opts,
>
> update_refs_for_switch(opts, &old_branch_info, new_branch_info);
>
> + if (opts->conflict_style >= 0) {
> + struct strbuf cfg = STRBUF_INIT;
> + strbuf_addf(&cfg, "merge.conflictStyle=%s",
> + conflict_style_name(opts->conflict_style));
> + git_config_push_parameter(cfg.buf);
This is rather unfortunate - it might be nicer for
create_autostash_internal() to set the conflict style.
> + strbuf_release(&cfg);
> + }
> + apply_autostash_ref_with_labels(the_repository, "CHECKOUT_AUTOSTASH_HEAD",
> + new_branch_info->name, "local",
> + stash_label_base,
> + autostash_msg.len ? autostash_msg.buf : NULL);
> +
> + discard_index(the_repository->index);
> + if (repo_read_index(the_repository) < 0)
> + die(_("index file corrupt"));
> +
> + if (created_autostash && !opts->discard_changes && !opts->quiet &&
Wouldn't it be a bug if we've created and autostash when
opts->discard_changes is set? Why do we need to check it?
> + new_branch_info->commit)
> + show_local_changes(&new_branch_info->commit->object,
> + &opts->diff_options);
So this is a change to the output when using "checkout -m"? If so it
might be better as a separate change.
I'll have to leave it there for now, I'll try and look at the rest of
the changes later in the week.
Thanks
Phillip
> +
> ret = post_checkout_hook(old_branch_info.commit, new_branch_info->commit, 1);
> branch_info_release(&old_branch_info);
> + strbuf_release(&old_commit_shortname);
> + strbuf_release(&autostash_msg);
>
> return ret || writeout_error;
> }
> diff --git a/sequencer.c b/sequencer.c
> index c2516000bd..b78a8ff092 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4770,15 +4770,23 @@ static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply,
> strvec_push(&store.args, stash_oid);
> if (run_command(&store))
> ret = error(_("cannot store %s"), stash_oid);
> + else if (attempt_apply)
> + fprintf(stderr,
> + _("Your local changes are stashed, however, applying it to carry\n"
> + "forward your local changes resulted in conflicts:\n"
> + "\n"
> + " - You can try resolving them now. If you resolved them\n"
> + " successfully, discard the stash entry with \"git stash drop\".\n"
> + "\n"
> + " - Alternatively you can \"git reset --hard\" if you do not want\n"
> + " to deal with them right now, and later \"git stash pop\" to\n"
> + " recover your local changes.\n"));
> else
> fprintf(stderr,
> - _("%s\n"
> + _("Autostash exists; creating a new stash entry.\n"
> "Your changes are safe in the stash.\n"
> "You can run \"git stash pop\" or"
> - " \"git stash drop\" at any time.\n"),
> - attempt_apply ?
> - _("Applying autostash resulted in conflicts.") :
> - _("Autostash exists; creating a new stash entry."));
> + " \"git stash drop\" at any time.\n"));
> }
>
> return ret;
> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
> index ad3ba6a984..e4e2cb19ce 100755
> --- a/t/t3420-rebase-autostash.sh
> +++ b/t/t3420-rebase-autostash.sh
> @@ -61,18 +61,30 @@ create_expected_failure_apply () {
> First, rewinding head to replay your work on top of it...
> Applying: second commit
> Applying: third commit
> - Applying autostash resulted in conflicts.
> - Your changes are safe in the stash.
> - You can run "git stash pop" or "git stash drop" at any time.
> + Your local changes are stashed, however, applying it to carry
> + forward your local changes resulted in conflicts:
> +
> + - You can try resolving them now. If you resolved them
> + successfully, discard the stash entry with "git stash drop".
> +
> + - Alternatively you can "git reset --hard" if you do not want
> + to deal with them right now, and later "git stash pop" to
> + recover your local changes.
> EOF
> }
>
> create_expected_failure_merge () {
> cat >expected <<-EOF
> $(grep "^Created autostash: [0-9a-f][0-9a-f]*\$" actual)
> - Applying autostash resulted in conflicts.
> - Your changes are safe in the stash.
> - You can run "git stash pop" or "git stash drop" at any time.
> + Your local changes are stashed, however, applying it to carry
> + forward your local changes resulted in conflicts:
> +
> + - You can try resolving them now. If you resolved them
> + successfully, discard the stash entry with "git stash drop".
> +
> + - Alternatively you can "git reset --hard" if you do not want
> + to deal with them right now, and later "git stash pop" to
> + recover your local changes.
> Successfully rebased and updated refs/heads/rebased-feature-branch.
> EOF
> }
> diff --git a/t/t7201-co.sh b/t/t7201-co.sh
> index 9bcf7c0b40..c474c6759f 100755
> --- a/t/t7201-co.sh
> +++ b/t/t7201-co.sh
> @@ -210,6 +210,214 @@ test_expect_success 'checkout --merge --conflict=diff3 <branch>' '
> test_cmp expect two
> '
>
> +test_expect_success 'checkout --merge --conflict=zdiff3 <branch>' '
> + git checkout -f main &&
> + git reset --hard &&
> + git clean -f &&
> +
> + fill a b X d e >two &&
> + git checkout --merge --conflict=zdiff3 simple &&
> +
> + cat <<-EOF >expect &&
> + a
> + <<<<<<< simple
> + c
> + ||||||| main
> + b
> + c
> + d
> + =======
> + b
> + X
> + d
> + >>>>>>> local
> + e
> + EOF
> + test_cmp expect two
> +'
> +
> +test_expect_success 'checkout -m respects merge.conflictStyle config' '
> + git checkout -f main &&
> + git reset --hard &&
> + git clean -f &&
> +
> + test_config merge.conflictStyle diff3 &&
> + fill b d >two &&
> + git checkout -m simple &&
> +
> + cat <<-EOF >expect &&
> + <<<<<<< simple
> + a
> + c
> + e
> + ||||||| main
> + a
> + b
> + c
> + d
> + e
> + =======
> + b
> + d
> + >>>>>>> local
> + EOF
> + test_cmp expect two
> +'
> +
> +test_expect_success 'checkout -m skips stash when no conflict' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 0 x y z >same &&
> + git stash list >stash-before &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + git stash list >stash-after &&
> + test_cmp stash-before stash-after &&
> + fill 0 x y z >expect &&
> + test_cmp expect same
> +'
> +
> +test_expect_success 'checkout -m skips stash with non-conflicting dirty index' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 0 x y z >same &&
> + git add same &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + fill 0 x y z >expect &&
> + test_cmp expect same
> +'
> +
> +test_expect_success 'checkout -m stashes and applies on conflicting changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 6 7 >one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + test_grep "Applied autostash" actual &&
> + fill 1 2 3 4 5 6 7 >expect &&
> + test_cmp expect one
> +'
> +
> +test_expect_success 'checkout -m with mixed staged and unstaged changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 0 x y z >same &&
> + git add same &&
> + fill 1 2 3 4 5 6 7 >one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + test_grep "Applied autostash" actual &&
> + fill 0 x y z >expect &&
> + test_cmp expect same &&
> + fill 1 2 3 4 5 6 7 >expect &&
> + test_cmp expect one
> +'
> +
> +test_expect_success 'checkout -m stashes on truly conflicting changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + test_must_fail git checkout side 2>stderr &&
> + test_grep "Your local changes" stderr &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + test_grep "resulted in conflicts" actual &&
> + test_grep "git stash drop" actual &&
> + git stash drop &&
> + git reset --hard
> +'
> +
> +test_expect_success 'checkout -m produces usable stash on conflict' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep "recover your local changes" actual &&
> + git checkout -f main &&
> + git stash pop &&
> + fill 1 2 3 4 5 >expect &&
> + test_cmp expect one
> +'
> +
> +test_expect_success 'checkout -m autostash message includes target branch' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + git checkout -m side >actual 2>&1 &&
> + git stash list >stash-list &&
> + test_grep "autostash while switching to .side." stash-list &&
> + git stash drop &&
> + git checkout -f main &&
> + git reset --hard
> +'
> +
> +test_expect_success 'checkout -m stashes on staged conflicting changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + git add one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + test_grep "resulted in conflicts" actual &&
> + test_grep "git stash drop" actual &&
> + git stash drop &&
> + git reset --hard
> +'
> +
> +test_expect_success 'checkout -m applies stash cleanly with non-overlapping changes in same file' '
> + git checkout -f main &&
> + git reset --hard &&
> + git clean -f &&
> +
> + git checkout -b nonoverlap_base &&
> + fill a b c d >file &&
> + git add file &&
> + git commit -m "add file" &&
> +
> + git checkout -b nonoverlap_child &&
> + fill a b c INSERTED d >file &&
> + git commit -a -m "insert line near end of file" &&
> +
> + fill DIRTY a b c INSERTED d >file &&
> +
> + git stash list >stash-before &&
> + git checkout -m nonoverlap_base 2>stderr &&
> + test_grep "Applied autostash" stderr &&
> + test_grep ! "resulted in conflicts" stderr &&
> +
> + git stash list >stash-after &&
> + test_cmp stash-before stash-after &&
> +
> + fill DIRTY a b c d >expect &&
> + test_cmp expect file &&
> +
> + git checkout -f main &&
> + git branch -D nonoverlap_base &&
> + git branch -D nonoverlap_child
> +'
> +
> +test_expect_success 'checkout -m -b skips stash with dirty tree' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 0 x y z >same &&
> + git checkout -m -b newbranch >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + fill 0 x y z >expect &&
> + test_cmp expect same &&
> + git checkout main &&
> + git branch -D newbranch
> +'
> +
> test_expect_success 'switch to another branch while carrying a deletion' '
> git checkout -f main &&
> git reset --hard &&
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 9838094b66..cbef8a534e 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -914,7 +914,7 @@ test_expect_success 'merge with conflicted --autostash changes' '
> git diff >expect &&
> test_when_finished "test_might_fail git stash drop" &&
> git merge --autostash c3 2>err &&
> - test_grep "Applying autostash resulted in conflicts." err &&
> + test_grep "your local changes resulted in conflicts" err &&
> git show HEAD:file >merge-result &&
> test_cmp result.1-9 merge-result &&
> git stash show -p >actual &&
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index f043330f2a..5ee2b96d0a 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -325,6 +325,18 @@ int parse_conflict_style_name(const char *value)
> return -1;
> }
>
> +const char *conflict_style_name(int style)
> +{
> + switch (style) {
> + case XDL_MERGE_DIFF3:
> + return "diff3";
> + case XDL_MERGE_ZEALOUS_DIFF3:
> + return "zdiff3";
> + default:
> + return "merge";
> + }
> +}
> +
> int git_xmerge_style = -1;
>
> int git_xmerge_config(const char *var, const char *value,
> diff --git a/xdiff-interface.h b/xdiff-interface.h
> index fbc4ceec40..ce54e1c0e0 100644
> --- a/xdiff-interface.h
> +++ b/xdiff-interface.h
> @@ -55,6 +55,7 @@ void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line, int cflags);
> void xdiff_clear_find_func(xdemitconf_t *xecfg);
> struct config_context;
> int parse_conflict_style_name(const char *value);
> +const char *conflict_style_name(int style);
> int git_xmerge_config(const char *var, const char *value,
> const struct config_context *ctx, void *cb);
> extern int git_xmerge_style;
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:07 [PATCH v12 4/4] checkout: -m (--merge) uses autostash when switching branches Phillip Wood
@ 2026-04-14 20:06 ` Harald Nordgren
2026-04-15 9:35 ` Phillip Wood
2026-04-14 20:13 ` Harald Nordgren
2026-04-15 8:16 ` Harald Nordgren
2 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 20:06 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> The changes up to here look like fixes for an existing bug and so would
> be better in a separate patch.
👍
> Sometimes we return "1" and sometimes "-1" what does that signal to the
> caller?
I just tried to follow a pattern, I'm not knowlegable of how this return code will be used. Futher down in the file we check 'ret == -1' and turn it into 1, so maybe 1 is correct?
> > + autostash_msg.len ? autostash_msg.buf : NULL);
>
> Can we create an autostash without setting a message in autostash_msg?
No, seems not. I'll simplify it!
> > + if (created_autostash && !opts->discard_changes && !opts->quiet &&
>
> Wouldn't it be a bug if we've created and autostash when
> opts->discard_changes is set? Why do we need to check it?
I'll simplify it!
> > + new_branch_info->commit)
> > + show_local_changes(&new_branch_info->commit->object,
> > + &opts->diff_options);
>
> So this is a change to the output when using "checkout -m"? If so it
> might be better as a separate change.
Do you mean to drop if from my patchset, or just make it a separate
commit within this series?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 20:06 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
@ 2026-04-15 9:35 ` Phillip Wood
0 siblings, 0 replies; 69+ messages in thread
From: Phillip Wood @ 2026-04-15 9:35 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood
On 14/04/2026 21:06, Harald Nordgren wrote:
>> The changes up to here look like fixes for an existing bug and so would
>> be better in a separate patch.
>
> 👍
>
>> Sometimes we return "1" and sometimes "-1" what does that signal to the
>> caller?
>
> I just tried to follow a pattern, I'm not knowlegable of how this return
> code will be used. Futher down in the file we check 'ret == -1' and
> turn it into 1, so maybe 1 is correct?
But you can read the code to see how it is used. Tracing the return path
of merge_working_tree(), the return value get propagated back up to the
top of the call stack i.e. cmd_checkout() or cmd_switch() and used as
the return value there. I had wondered if we were using the value on the
way back up the stack and doing something different based on the whether
it was "1" or "-1" but we don't so it only affects the exit code of "git
checkout". That means returning "1" is sensible I think.
> Do you mean to drop if from my patchset, or just make it a separate
> commit within this series?
A separate commit in this series. As "git checkout" without "-m" can
also carry local changes across we probably should do the same there as
well.
Thanks
Phillip
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:07 [PATCH v12 4/4] checkout: -m (--merge) uses autostash when switching branches Phillip Wood
2026-04-14 20:06 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
@ 2026-04-14 20:13 ` Harald Nordgren
2026-04-15 8:19 ` Harald Nordgren
2026-04-15 8:16 ` Harald Nordgren
2 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 20:13 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> > + strbuf_addf(&autostash_msg,
> > + "autostash while switching to '%s'",
> > + new_branch_info->name);
> > + create_autostash_ref_with_msg_silent(the_repository,
> > + "CHECKOUT_AUTOSTASH_HEAD",
>
> It's a shame we have to create a ref here. MERGE_AUTOSTASH exists so
> that "git merge --continue" can apply the stash once the user has
> resolved any merge conflicts. We don't have that problem here because
> there is no user interaction and we could just hold onto the stash oid
> in a variable.
I don't know how to actually do that. Maybe better to do later?
> > + autostash_msg.buf);
> > + created_autostash = 1;
> > + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> > + }
> > if (ret) {
>
> I'm confused by this - if we stash then don't we expect the call to
> unpack_trees() in merge_working_tree() to succeed and therefore return
> 0? If opts->merge is false then we should not be trying to apply the
> stash when merge_working_tree() fails.
Same here, I'm not sure how to get this to work. Maybe better to do later?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 20:13 ` Harald Nordgren
@ 2026-04-15 8:19 ` Harald Nordgren
2026-04-15 9:34 ` Phillip Wood
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-15 8:19 UTC (permalink / raw)
To: haraldnordgren
Cc: chris.torek, git, gitgitgadget, peff, phillip.wood123,
phillip.wood
> > > + strbuf_addf(&autostash_msg,
> > > + "autostash while switching to '%s'",
> > > + new_branch_info->name);
> > > + create_autostash_ref_with_msg_silent(the_repository,
> > > + "CHECKOUT_AUTOSTASH_HEAD",
> >
> > It's a shame we have to create a ref here. MERGE_AUTOSTASH exists so
> > that "git merge --continue" can apply the stash once the user has
> > resolved any merge conflicts. We don't have that problem here because
> > there is no user interaction and we could just hold onto the stash oid
> > in a variable.
>
> I don't know how to actually do that. Maybe better to do later?
A gave this a try, but it becomes a very big change. Or maybe I'm missing
some key knowledge here.
> > > + autostash_msg.buf);
> > > + created_autostash = 1;
> > > + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> > > + }
> > > if (ret) {
> >
> > I'm confused by this - if we stash then don't we expect the call to
> > unpack_trees() in merge_working_tree() to succeed and therefore return
> > 0? If opts->merge is false then we should not be trying to apply the
> > stash when merge_working_tree() fails.
>
> Same here, I'm not sure how to get this to work. Maybe better to do later?
I think I succeeded with this one.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-15 8:19 ` Harald Nordgren
@ 2026-04-15 9:34 ` Phillip Wood
0 siblings, 0 replies; 69+ messages in thread
From: Phillip Wood @ 2026-04-15 9:34 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood
On 15/04/2026 09:19, Harald Nordgren wrote:
>>>> + strbuf_addf(&autostash_msg,
>>>> + "autostash while switching to '%s'",
>>>> + new_branch_info->name);
>>>> + create_autostash_ref_with_msg_silent(the_repository,
>>>> + "CHECKOUT_AUTOSTASH_HEAD",
>>>
>>> It's a shame we have to create a ref here. MERGE_AUTOSTASH exists so
>>> that "git merge --continue" can apply the stash once the user has
>>> resolved any merge conflicts. We don't have that problem here because
>>> there is no user interaction and we could just hold onto the stash oid
>>> in a variable.
>>
>> I don't know how to actually do that. Maybe better to do later?
>
> A gave this a try, but it becomes a very big change. Or maybe I'm missing
> some key knowledge here.
Maybe leave that for now then
>>>> + autostash_msg.buf);
>>>> + created_autostash = 1;
>>>> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
>>>> + }
>>>> if (ret) {
>>>
>>> I'm confused by this - if we stash then don't we expect the call to
>>> unpack_trees() in merge_working_tree() to succeed and therefore return
>>> 0?
In that case we apply the stash lower down so that's fine.
>>> If opts->merge is false then we should not be trying to apply the
>>> stash when merge_working_tree() fails.
>>
>> Same here, I'm not sure how to get this to work. Maybe better to do later?
>
> I think I succeeded with this one.
This one definitely needs fixing but it should be simple to do as I
think it is just a logic error. We should not be trying to re-apply the
stash unless we created it and we can check "created_autostash" to do that.
Thanks
Phillip
>
>
> Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:07 [PATCH v12 4/4] checkout: -m (--merge) uses autostash when switching branches Phillip Wood
2026-04-14 20:06 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-14 20:13 ` Harald Nordgren
@ 2026-04-15 8:16 ` Harald Nordgren
2026-04-15 9:36 ` Phillip Wood
2 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-15 8:16 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> > + if (old_branch_info.name)
> > + stash_label_base = old_branch_info.name;
> > + else if (old_branch_info.commit) {
> > + strbuf_add_unique_abbrev(&old_commit_shortname,
> > + &old_branch_info.commit->object.oid,
> > + DEFAULT_ABBREV);
> > + stash_label_base = old_commit_shortname.buf;
> > + }
> > +
> > if (do_merge) {
> > ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> > + if (ret && opts->merge) {
>
> As we saw above merge_working_tree() can return non-zero for a variety
> of reasons. We only want to try stashing if the call to unpack_trees()
> failed. Even then if you look at the list of errors in unpack-trees.h
> you'll see that only a few of them relate to problems that can be solved
> by stashing. The old code just tried merging whenever unpack_trees()
> failed so it probably not so bad to do the same here but we should not
> be stashing if merge_working_tree() returns before calling unpack_trees().
What you are saying makes a lot of sense.
I gave this a shot now, trying to return an error code that only attempts
the stashing when it has a chance of improving the outcome. Not at all sure
if it's correct though!
> > + autostash_msg.buf);
> > + created_autostash = 1;
> > + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> > + }
> > if (ret) {
>
> I'm confused by this - if we stash then don't we expect the call to
> unpack_trees() in merge_working_tree() to succeed and therefore return
> 0? If opts->merge is false then we should not be trying to apply the
> stash when merge_working_tree() fails.
I'm attempting to fix this by making call to apply_autostash_ref
conditional on whether or not the autostash was actually created. Makes
sense?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-15 8:16 ` Harald Nordgren
@ 2026-04-15 9:36 ` Phillip Wood
0 siblings, 0 replies; 69+ messages in thread
From: Phillip Wood @ 2026-04-15 9:36 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood
On 15/04/2026 09:16, Harald Nordgren wrote:
>>> + if (old_branch_info.name)
>>> + stash_label_base = old_branch_info.name;
>>> + else if (old_branch_info.commit) {
>>> + strbuf_add_unique_abbrev(&old_commit_shortname,
>>> + &old_branch_info.commit->object.oid,
>>> + DEFAULT_ABBREV);
>>> + stash_label_base = old_commit_shortname.buf;
>>> + }
>>> +
>>> if (do_merge) {
>>> ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
>>> + if (ret && opts->merge) {
>>
>> As we saw above merge_working_tree() can return non-zero for a variety
>> of reasons. We only want to try stashing if the call to unpack_trees()
>> failed. Even then if you look at the list of errors in unpack-trees.h
>> you'll see that only a few of them relate to problems that can be solved
>> by stashing. The old code just tried merging whenever unpack_trees()
>> failed so it probably not so bad to do the same here but we should not
>> be stashing if merge_working_tree() returns before calling unpack_trees().
>
> What you are saying makes a lot of sense.
>
> I gave this a shot now, trying to return an error code that only attempts
> the stashing when it has a chance of improving the outcome. Not at all sure
> if it's correct though!
That sounds like the right approach
>>> + autostash_msg.buf);
>>> + created_autostash = 1;
>>> + ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
>>> + }
>>> if (ret) {
>>
>> I'm confused by this - if we stash then don't we expect the call to
>> unpack_trees() in merge_working_tree() to succeed and therefore return
>> 0? If opts->merge is false then we should not be trying to apply the
>> stash when merge_working_tree() fails.
>
> I'm attempting to fix this by making call to apply_autostash_ref
> conditional on whether or not the autostash was actually created. Makes
> sense?
Yes, exactly
Thanks
Phillip
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v12 3/4] sequencer: teach autostash apply to take optional conflict marker labels
@ 2026-04-14 14:06 Phillip Wood
2026-04-14 18:44 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-14 14:06 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 14/04/2026 13:59, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Add label_ours, label_theirs, and label_base parameters to the autostash
> apply machinery so callers can pass custom conflict marker labels
> through to "git stash apply --label-ours/--label-theirs/--label-base".
> Introduce apply_autostash_ref_with_labels() for callers that want
> to pass labels.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> [...]
> diff --git a/sequencer.c b/sequencer.c
> index 780628aab4..c2516000bd 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4732,7 +4732,10 @@ void create_autostash_ref_with_msg_silent(struct repository *r, const char *refn
> create_autostash_internal(r, NULL, refname, message, true);
> }
>
> -static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
> +static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply,
> + const char *label_ours, const char *label_theirs,
> + const char *label_base,
> + const char *stash_msg)
I'm confused why to need to provide a message when we're storing an
existing stash that already has the message that we want to use.
> diff --git a/sequencer.h b/sequencer.h
> index 5d3bc83314..b0c891d3b6 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -237,6 +237,10 @@ int save_autostash_ref(struct repository *r, const char *refname);
> int apply_autostash(const char *path);
> int apply_autostash_oid(const char *stash_oid);
> int apply_autostash_ref(struct repository *r, const char *refname);
> +int apply_autostash_ref_with_labels(struct repository *r, const char *refname,
> + const char *label_ours, const char *label_theirs,
> + const char *label_base,
> + const char *stash_msg);
Do we need a new function, or can we just update the existing callers to
pass NULL? In the future I think we'll want to pass better conflict
labels and updating them now to pass NULL makes that easier.
Thanks
Phillip
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:06 [PATCH v12 3/4] sequencer: teach autostash apply to take optional conflict marker labels Phillip Wood
@ 2026-04-14 18:44 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 18:44 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> > diff --git a/sequencer.h b/sequencer.h
> > index 5d3bc83314..b0c891d3b6 100644
> > --- a/sequencer.h
> > +++ b/sequencer.h
> > @@ -237,6 +237,10 @@ int save_autostash_ref(struct repository *r, const char *refname);
> > int apply_autostash(const char *path);
> > int apply_autostash_oid(const char *stash_oid);
> > int apply_autostash_ref(struct repository *r, const char *refname);
> > +int apply_autostash_ref_with_labels(struct repository *r, const char *refname,
> > + const char *label_ours, const char *label_theirs,
> > + const char *label_base,
> > + const char *stash_msg);
Fair enough, will update in the next patch!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v12 2/4] sequencer: allow create_autostash to run silently
@ 2026-04-14 14:06 Phillip Wood
2026-04-14 18:35 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-14 14:06 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 14/04/2026 13:59, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Add a silent parameter to create_autostash_internal and introduce
> create_autostash_ref_silent so that callers can create an autostash
> without printing the "Created autostash" message.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
I wonder if we should just update the two callers of
create_autostash_ref() instead of adding a new function but the
implementation looks sensible
Thanks
Phillip
> sequencer.c | 20 +++++++++++++++-----
> sequencer.h | 2 ++
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index b7d8dca47f..780628aab4 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4657,7 +4657,9 @@ static enum todo_command peek_command(struct todo_list *todo_list, int offset)
>
> static void create_autostash_internal(struct repository *r,
> const char *path,
> - const char *refname)
> + const char *refname,
> + const char *message,
> + bool silent)
> {
> struct strbuf buf = STRBUF_INIT;
> struct lock_file lock_file = LOCK_INIT;
> @@ -4679,7 +4681,8 @@ static void create_autostash_internal(struct repository *r,
> struct object_id oid;
>
> strvec_pushl(&stash.args,
> - "stash", "create", "autostash", NULL);
> + "stash", "create",
> + message ? message : "autostash", NULL);
> stash.git_cmd = 1;
> stash.no_stdin = 1;
> strbuf_reset(&buf);
> @@ -4702,7 +4705,8 @@ static void create_autostash_internal(struct repository *r,
> &oid, null_oid(the_hash_algo), 0, UPDATE_REFS_DIE_ON_ERR);
> }
>
> - printf(_("Created autostash: %s\n"), buf.buf);
> + if (!silent)
> + printf(_("Created autostash: %s\n"), buf.buf);
> if (reset_head(r, &ropts) < 0)
> die(_("could not reset --hard"));
> discard_index(r->index);
> @@ -4714,12 +4718,18 @@ static void create_autostash_internal(struct repository *r,
>
> void create_autostash(struct repository *r, const char *path)
> {
> - create_autostash_internal(r, path, NULL);
> + create_autostash_internal(r, path, NULL, NULL, false);
> }
>
> void create_autostash_ref(struct repository *r, const char *refname)
> {
> - create_autostash_internal(r, NULL, refname);
> + create_autostash_internal(r, NULL, refname, NULL, false);
> +}
> +
> +void create_autostash_ref_with_msg_silent(struct repository *r, const char *refname,
> + const char *message)
> +{
> + create_autostash_internal(r, NULL, refname, message, true);
> }
>
> static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
> diff --git a/sequencer.h b/sequencer.h
> index a6fa670c7c..5d3bc83314 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -230,6 +230,8 @@ void commit_post_rewrite(struct repository *r,
>
> void create_autostash(struct repository *r, const char *path);
> void create_autostash_ref(struct repository *r, const char *refname);
> +void create_autostash_ref_with_msg_silent(struct repository *r, const char *refname,
> + const char *message);
> int save_autostash(const char *path);
> int save_autostash_ref(struct repository *r, const char *refname);
> int apply_autostash(const char *path);
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:06 [PATCH v12 2/4] sequencer: allow create_autostash to run silently Phillip Wood
@ 2026-04-14 18:35 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 18:35 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> > From: Harald Nordgren <haraldnordgren@gmail.com>
> >
> > Add a silent parameter to create_autostash_internal and introduce
> > create_autostash_ref_silent so that callers can create an autostash
> > without printing the "Created autostash" message.
> >
> > Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
>
> I wonder if we should just update the two callers of
> create_autostash_ref() instead of adding a new function but the
> implementation looks sensible
Good point, I will update it!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v12 1/4] stash: add --label-ours, --label-theirs, --label-base for apply
@ 2026-04-14 14:05 Phillip Wood
2026-04-14 18:56 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-14 20:08 ` Harald Nordgren
0 siblings, 2 replies; 69+ messages in thread
From: Phillip Wood @ 2026-04-14 14:05 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git
Cc: Chris Torek, Jeff King, Harald Nordgren
Hi Harald
On 14/04/2026 13:59, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Allow callers of "git stash apply" to pass custom labels for conflict
> markers instead of the default "Updated upstream" and "Stashed changes".
> Document the new options and add a test.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> [...]
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 0d27b2fb1f..00314e2b13 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -44,7 +44,7 @@
> [...]
> -static int do_apply_stash(const char *prefix, struct stash_info *info,
> - int index, int quiet)
> +static int do_apply_stash_with_labels(const char *prefix,
> + struct stash_info *info,
> + int index, int quiet,
> + const char *label_ours, const char *label_theirs,
> + const char *label_base)
There are only four callers of do_apply_stash so it might be better just
to change the function signature and update the existing callers rather
than adding another function.
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 70879941c2..00bcb1f802 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -1666,6 +1666,35 @@ test_expect_success 'restore untracked files even when we hit conflicts' '
> )
> '
>
> +test_expect_success 'apply with custom conflict labels' '
> + git init conflict_labels &&
> + (
I'm still unclear why we're creating a new repository here. Our test
suite is slow enough already without each test spending time creating
its own repository. There doesn't seem to be anything here that requires
isolating the test in this way.
Apart from that everything else looks good to me
Thanks
Phillip
> + cd conflict_labels &&
> + test_commit base file &&
> + echo stashed >file &&
> + git stash push -m "stashed" &&
> + test_commit upstream file &&
> + test_must_fail git -c merge.conflictStyle=diff3 stash apply --label-ours=UP --label-theirs=STASH &&
> + test_grep "^<<<<<<< UP" file &&
> + test_grep "^||||||| Stash base" file &&
> + test_grep "^>>>>>>> STASH" file
> + )
> +'
> +
> +test_expect_success 'apply with empty conflict labels' '
> + git init empty_labels &&
> + (
> + cd empty_labels &&
> + test_commit base file &&
> + echo stashed >file &&
> + git stash push -m "stashed" &&
> + test_commit upstream file &&
> + test_must_fail git stash apply --label-ours= --label-theirs= &&
> + test_grep "^<<<<<<<$" file &&
> + test_grep "^>>>>>>>$" file
> + )
> +'
> +
> test_expect_success 'stash create reports a locked index' '
> test_when_finished "rm -rf repo" &&
> git init repo &&
> diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
> index 29dad98c49..659ad4ec97 100644
> --- a/xdiff/xmerge.c
> +++ b/xdiff/xmerge.c
> @@ -199,9 +199,9 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char *name1,
> int size, int i, int style,
> xdmerge_t *m, char *dest, int marker_size)
> {
> - int marker1_size = (name1 ? strlen(name1) + 1 : 0);
> - int marker2_size = (name2 ? strlen(name2) + 1 : 0);
> - int marker3_size = (name3 ? strlen(name3) + 1 : 0);
> + int marker1_size = (name1 && *name1 ? strlen(name1) + 1 : 0);
> + int marker2_size = (name2 && *name2 ? strlen(name2) + 1 : 0);
> + int marker3_size = (name3 && *name3 ? strlen(name3) + 1 : 0);
> int needs_cr = is_cr_needed(xe1, xe2, m);
>
> if (marker_size <= 0)
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:05 [PATCH v12 1/4] stash: add --label-ours, --label-theirs, --label-base for apply Phillip Wood
@ 2026-04-14 18:56 ` Harald Nordgren
2026-04-14 20:08 ` Harald Nordgren
1 sibling, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 18:56 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> There are only four callers of do_apply_stash so it might be better just
> to change the function signature and update the existing callers rather
> than adding another function.
Also a good point, and I will update it.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 14:05 [PATCH v12 1/4] stash: add --label-ours, --label-theirs, --label-base for apply Phillip Wood
2026-04-14 18:56 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
@ 2026-04-14 20:08 ` Harald Nordgren
2026-04-15 9:34 ` Phillip Wood
1 sibling, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 20:08 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> > +test_expect_success 'apply with custom conflict labels' '
> > + git init conflict_labels &&
> > + (
>
> I'm still unclear why we're creating a new repository here. Our test
> suite is slow enough already without each test spending time creating
> its own repository. There doesn't seem to be anything here that requires
> isolating the test in this way.
Yes, I want this too, but I had some problems to get it to work. Found a
way now I think, but the cleanup is not 100% trivial (this is the only
reason to run anything inside a new repo).
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 20:08 ` Harald Nordgren
@ 2026-04-15 9:34 ` Phillip Wood
2026-04-15 15:34 ` Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-15 9:34 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood
On 14/04/2026 21:08, Harald Nordgren wrote:
>>> +test_expect_success 'apply with custom conflict labels' '
>>> + git init conflict_labels &&
>>> + (
>>
>> I'm still unclear why we're creating a new repository here. Our test
>> suite is slow enough already without each test spending time creating
>> its own repository. There doesn't seem to be anything here that requires
>> isolating the test in this way.
>
> Yes, I want this too, but I had some problems to get it to work. Found a
> way now I think, but the cleanup is not 100% trivial (this is the only
> reason to run anything inside a new repo).
Normally the first test would setup some commits with test_commit() that
creates a tag so you can just use "git reset --hard <tag>" to start your
test from a known state. Unfortunately setup_stash() does not use
test_commit() so there are no tags. It would be useful to fix that by
adding a line that creates a tag so that future test authors do not face
the same problem.
Thanks
Phillip
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-15 9:34 ` Phillip Wood
@ 2026-04-15 15:34 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-15 15:34 UTC (permalink / raw)
To: phillip.wood123
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood
> Normally the first test would setup some commits with test_commit() that
> creates a tag so you can just use "git reset --hard <tag>" to start your
> test from a known state. Unfortunately setup_stash() does not use
> test_commit() so there are no tags. It would be useful to fix that by
> adding a line that creates a tag so that future test authors do not face
> the same problem.
Sounds reasonable, but it's surprisingly easy to break the subsequent
tests.
My solution now will be to move these tests to last in the test file.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v10 0/4] checkout: 'autostash' for branch switching
@ 2026-04-13 22:45 Junio C Hamano
2026-04-14 7:29 ` [PATCH] checkout: add --autostash option " Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-13 22:45 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget
Cc: git, Phillip Wood, Chris Torek, Jeff King, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Harald Nordgren (4):
> stash: add --label-ours, --label-theirs, --label-base for apply
> sequencer: allow create_autostash to run silently
> sequencer: teach autostash apply to take optional conflict marker
> labels
> checkout: -m (--merge) uses autostash when switching branches
I have been trying this in my real workflow and noticed only one
minor annoyance, which is that the stash entry only says
"autostash", which is not very illuminating.
Because I almost always have either 'master' or 'next' checked out,
when I start outlining a "how about this" kind of change, they are
made on top of these branches, but when I say "checkout -m topic"
after that, I _know_ that the rough draft change that becomes a
stash entry is meant to be part of the "topic", either to extend it
or refine it. Because the code that creates the stash entry knows
that we were in the process of moving to 'topic', it would be nice
to see the name of the branch we are moving to (i.e., 'topic') on
the title, e.g., "autostash while switching to 'topic'".
Other than that, it is a very pleasant usability enhancement.
Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-13 22:45 [PATCH v10 0/4] checkout: 'autostash' " Junio C Hamano
@ 2026-04-14 7:29 ` Harald Nordgren
2026-04-14 13:29 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-14 7:29 UTC (permalink / raw)
To: gitster
Cc: chris.torek, git, gitgitgadget, haraldnordgren, peff,
phillip.wood123
> Because I almost always have either 'master' or 'next' checked out,
> when I start outlining a "how about this" kind of change, they are
> made on top of these branches, but when I say "checkout -m topic"
> after that, I _know_ that the rough draft change that becomes a
> stash entry is meant to be part of the "topic", either to extend it
> or refine it. Because the code that creates the stash entry knows
> that we were in the process of moving to 'topic', it would be nice
> to see the name of the branch we are moving to (i.e., 'topic') on
> the title, e.g., "autostash while switching to 'topic'".
Sounds reasonable, but wouldn't it make more sense to call it "autostash
from master". We should still be able to abort the merge and merge it to
some other branch. I feel like the source is more relevant than the
destination, no?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 7:29 ` [PATCH] checkout: add --autostash option " Harald Nordgren
@ 2026-04-14 13:29 ` Junio C Hamano
2026-04-14 14:14 ` Junio C Hamano
2026-04-14 17:42 ` Junio C Hamano
0 siblings, 2 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-04-14 13:29 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood123
Harald Nordgren <haraldnordgren@gmail.com> writes:
> Sounds reasonable, but wouldn't it make more sense to call it "autostash
> from master". We should still be able to abort the merge and merge it to
> some other branch. I feel like the source is more relevant than the
> destination, no?
The new comment is for reminder, so "I made this while switching
from 'master' to this new 'topic'" theoretically has more reminding
value than "I made this while switching to this new 'topic'". As I
outlined my workflow, I usually am on 'master' or 'next' when I end
up needing "co -m" option, so "I was on 'master' when I stashed
this" has a much weaker reminding value. Just like a series of
"autostash" without any context comment irritated me, I'll see many
"autostash on master" that I cannot quite distinguish.
But that may be just me.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 13:29 ` Junio C Hamano
@ 2026-04-14 14:14 ` Junio C Hamano
2026-04-14 17:42 ` Junio C Hamano
1 sibling, 0 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-04-14 14:14 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood123
Junio C Hamano <gitster@pobox.com> writes:
> Harald Nordgren <haraldnordgren@gmail.com> writes:
>
>> Sounds reasonable, but wouldn't it make more sense to call it "autostash
>> from master". We should still be able to abort the merge and merge it to
>> some other branch. I feel like the source is more relevant than the
>> destination, no?
>
> The new comment is for reminder, so "I made this while switching
> from 'master' to this new 'topic'" theoretically has more reminding
> value than "I made this while switching to this new 'topic'". As I
> outlined my workflow, I usually am on 'master' or 'next' when I end
> up needing "co -m" option, so "I was on 'master' when I stashed
> this" has a much weaker reminding value. Just like a series of
> "autostash" without any context comment irritated me, I'll see many
> "autostash on master" that I cannot quite distinguish.
>
> But that may be just me.
In any case, the topic is already in 'next' and this kind of minor
tweaks are best done as a separate topic once the basic framework
that works reasonably well is established on top. We may end up
wanting some mechanism to customize the message in the end but that
is something we will find out and become able to decide on the best
design only after we let users use it for a while.
Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-14 13:29 ` Junio C Hamano
2026-04-14 14:14 ` Junio C Hamano
@ 2026-04-14 17:42 ` Junio C Hamano
1 sibling, 0 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-04-14 17:42 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, peff, phillip.wood123
Junio C Hamano <gitster@pobox.com> writes:
> Harald Nordgren <haraldnordgren@gmail.com> writes:
>
>> Sounds reasonable, but wouldn't it make more sense to call it "autostash
>> from master". We should still be able to abort the merge and merge it to
>> some other branch. I feel like the source is more relevant than the
>> destination, no?
>
> The new comment is for reminder, so "I made this while switching
> from 'master' to this new 'topic'" theoretically has more reminding
> value than "I made this while switching to this new 'topic'". As I
> outlined my workflow, I usually am on 'master' or 'next' when I end
> up needing "co -m" option, so "I was on 'master' when I stashed
> this" has a much weaker reminding value. Just like a series of
> "autostash" without any context comment irritated me, I'll see many
> "autostash on master" that I cannot quite distinguish.
>
> But that may be just me.
Thinking about it a bit more, I doubt it would be just me.
The whole point of "git checkout -m other-branch" is "oops, I
started working on this thing while I am on <this> branch, but all
of this changes are irrelevant in the context of this branch and I
realize that they are better done in the context of that other
branch". So as a name that reminds readers of "git stash list" what
this particular stash entry is about, the name of that other branch
you were switching to is much more relevant than the branch you were
on when you started working on.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v9 4/4] checkout: -m (--merge) uses autostash when switching branches
@ 2026-04-11 18:38 Jeff King
2026-04-11 18:51 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Jeff King @ 2026-04-11 18:38 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget
Cc: git, Phillip Wood, Chris Torek, Harald Nordgren
On Fri, Apr 10, 2026 at 09:01:13PM +0000, Harald Nordgren via GitGitGadget wrote:
> if (do_merge) {
> ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
> + if (ret && opts->merge) {
> + create_autostash_ref_silent(the_repository,
> + "CHECKOUT_AUTOSTASH");
This tries to create a root-level ref called CHECKOUT_AUTOSTASH, which
violates the syntax rules given in gitglossary's "ref" entry:
Ref names must either start with refs/ or be located in the root of
the hierarchy. For the latter, their name must follow these rules:
• The name consists of only upper-case characters or underscores.
• The name ends with "_HEAD" or is equal to "HEAD".
Our enforcement of these rules has some holes, but I have a local series
to fix that (which is how I noticed the problem). The entry continues to
list some exceptions:
There are some irregular refs in the root of the hierarchy that do not
match these rules. The following list is exhaustive and shall not be
extended in the future:
• AUTO_MERGE
• BISECT_EXPECTED_REV
• NOTES_MERGE_PARTIAL
• NOTES_MERGE_REF
• MERGE_AUTOSTASH
We can add CHECKOUT_AUTOSTASH to the list of exceptions, but I wonder if
there is another name we could use that would conform to the usual
rules.
-Peff
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-11 18:38 [PATCH v9 4/4] checkout: -m (--merge) uses autostash when switching branches Jeff King
@ 2026-04-11 18:51 ` Harald Nordgren
2026-04-11 19:11 ` Jeff King
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-11 18:51 UTC (permalink / raw)
To: peff; +Cc: chris.torek, git, gitgitgadget, haraldnordgren, phillip.wood123
> This tries to create a root-level ref called CHECKOUT_AUTOSTASH, which
> violates the syntax rules given in gitglossary's "ref" entry:
>
> Ref names must either start with refs/ or be located in the root of
> the hierarchy. For the latter, their name must follow these rules:
>
> • The name consists of only upper-case characters or underscores.
>
> • The name ends with "_HEAD" or is equal to "HEAD".
So maybe easiest is just to rename it to CHECKOUT_AUTOSTASH_HEAD?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-11 18:51 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
@ 2026-04-11 19:11 ` Jeff King
0 siblings, 0 replies; 69+ messages in thread
From: Jeff King @ 2026-04-11 19:11 UTC (permalink / raw)
To: Harald Nordgren; +Cc: chris.torek, git, gitgitgadget, phillip.wood123
On Sat, Apr 11, 2026 at 08:51:09PM +0200, Harald Nordgren wrote:
> > This tries to create a root-level ref called CHECKOUT_AUTOSTASH, which
> > violates the syntax rules given in gitglossary's "ref" entry:
> >
> > Ref names must either start with refs/ or be located in the root of
> > the hierarchy. For the latter, their name must follow these rules:
> >
> > • The name consists of only upper-case characters or underscores.
> >
> > • The name ends with "_HEAD" or is equal to "HEAD".
>
>
> So maybe easiest is just to rename it to CHECKOUT_AUTOSTASH_HEAD?
Yeah, that is syntactically valid, if a mouthful. I can't offhand think
of a shorter variant.
-Peff
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v8 3/4] sequencer: teach autostash apply to take optional conflict marker labels
@ 2026-04-10 16:34 Junio C Hamano
2026-04-10 18:48 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-10 16:34 UTC (permalink / raw)
To: Phillip Wood; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
> Hi Harald
>
> On 09/04/2026 20:17, Harald Nordgren via GitGitGadget wrote:
>> From: Harald Nordgren <haraldnordgren@gmail.com>
>>
>> Add label1, label2, and label_ancestor parameters to the autostash
Sorry, I just noticed that these three should have been updated when
the actual parameters were renamed.
>> apply machinery so callers can pass custom conflict marker labels
>> through to "git stash apply --ours-label/--theirs-label/--base-label".
>> Introduce apply_autostash_ref_with_labels() for callers that want
>> to pass labels.
>
> This looks good. In the future we could use this to set some better
> labels for "git rebase --autostash" but that does not need to be part of
> this series.
Great.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v8 2/4] sequencer: allow create_autostash to run silently
@ 2026-04-10 15:39 Phillip Wood
2026-04-10 18:53 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-10 15:39 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git; +Cc: Harald Nordgren
Hi Harald
On 09/04/2026 20:17, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Add a silent parameter to create_autostash_internal and introduce
> create_autostash_ref_silent so that callers can create an autostash
> without printing the "Created autostash" message. Use stderr for
> the message when not silent.
Why do we want to change where the message is printed? It is not
necessarily a bad idea but it would be helpful to explain why we want
that particular change.
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> sequencer.c | 15 +++++++++++----
> sequencer.h | 1 +
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index b7d8dca47f..e500a94a59 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4657,7 +4657,8 @@ static enum todo_command peek_command(struct todo_list *todo_list, int offset)
>
> static void create_autostash_internal(struct repository *r,
> const char *path,
> - const char *refname)
> + const char *refname,
> + int silent)
This could be a "bool" and the users could pass "true" and "false".
Apart from that this looks good.
Thanks
Phillip
> {
> struct strbuf buf = STRBUF_INIT;
> struct lock_file lock_file = LOCK_INIT;
> @@ -4702,7 +4703,8 @@ static void create_autostash_internal(struct repository *r,
> &oid, null_oid(the_hash_algo), 0, UPDATE_REFS_DIE_ON_ERR);
> }
>
> - printf(_("Created autostash: %s\n"), buf.buf);
> + if (!silent)
> + fprintf(stderr, _("Created autostash: %s\n"), buf.buf);
> if (reset_head(r, &ropts) < 0)
> die(_("could not reset --hard"));
> discard_index(r->index);
> @@ -4714,12 +4716,17 @@ static void create_autostash_internal(struct repository *r,
>
> void create_autostash(struct repository *r, const char *path)
> {
> - create_autostash_internal(r, path, NULL);
> + create_autostash_internal(r, path, NULL, 0);
> }
>
> void create_autostash_ref(struct repository *r, const char *refname)
> {
> - create_autostash_internal(r, NULL, refname);
> + create_autostash_internal(r, NULL, refname, 0);
> +}
> +
> +void create_autostash_ref_silent(struct repository *r, const char *refname)
> +{
> + create_autostash_internal(r, NULL, refname, 1);
> }
>
> static int apply_save_autostash_oid(const char *stash_oid, int attempt_apply)
> diff --git a/sequencer.h b/sequencer.h
> index a6fa670c7c..570f804457 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -230,6 +230,7 @@ void commit_post_rewrite(struct repository *r,
>
> void create_autostash(struct repository *r, const char *path);
> void create_autostash_ref(struct repository *r, const char *refname);
> +void create_autostash_ref_silent(struct repository *r, const char *refname);
> int save_autostash(const char *path);
> int save_autostash_ref(struct repository *r, const char *refname);
> int apply_autostash(const char *path);
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v8 1/4] stash: add --ours-label, --theirs-label, --base-label for apply
@ 2026-04-10 15:39 Phillip Wood
2026-04-10 19:18 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-04-10 15:39 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget, git; +Cc: Harald Nordgren
Hi Harald
On 09/04/2026 20:17, Harald Nordgren via GitGitGadget wrote:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Allow callers of "git stash apply" to pass custom labels for conflict
> markers instead of the default "Updated upstream" and "Stashed changes".
> Document the new options and add a test.
Sounds sensible and the documentation looks good.
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 0d27b2fb1f..54bcb6ac73 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -44,7 +44,7 @@
> #define BUILTIN_STASH_POP_USAGE \
> N_("git stash pop [--index] [-q | --quiet] [<stash>]")
> #define BUILTIN_STASH_APPLY_USAGE \
> - N_("git stash apply [--index] [-q | --quiet] [<stash>]")
> + N_("git stash apply [--index] [-q | --quiet] [--ours-label=<label>] [--theirs-label=<label>] [--base-label=<label>] [<stash>]")
> #define BUILTIN_STASH_BRANCH_USAGE \
> N_("git stash branch <branchname> [<stash>]")
> #define BUILTIN_STASH_STORE_USAGE \
This patch seems to be missing the implementation of these new options.
Before submitting a patch series I find it is very helpful to run
git rebase --keep-base -x make -x 'cd t && prove -j6 <tests that I
think might fail>'
to catch any mistakes.
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 70879941c2..d4e4e4d7b6 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -1666,6 +1666,43 @@ test_expect_success 'restore untracked files even when we hit conflicts' '
> )
> '
>
> +test_expect_success 'apply with custom conflict labels' '
> + git init conflict_labels &&
Why do we need to create a new repository just to stash some changes?
> + (
> + cd conflict_labels &&
> + echo base >file &&
> + git add file &&
> + git commit -m base &&
We have a helper test_commit() for creating commits (it is documented in
t/test-lib-functions.sh)
> + echo stashed >file &&
> + git stash push -m "stashed" &&
> + echo upstream >file &&
> + git add file &&
> + git commit -m upstream &&
> + test_must_fail git -c merge.conflictStyle=diff3 stash apply --ours-label=UP --theirs-label=STASH &&
> + test_grep "^<<<<<<< UP" file &&
> + test_grep "^||||||| Stash base" file &&
> + test_grep "^>>>>>>> STASH" file
Hurray for the use of test_grep here!
> + )
> +'
> +
> +test_expect_success 'apply with empty conflict labels' '
Why do we want to support empty labels rather than making them an error?
Thanks
Phillip
> + git init empty_labels &&
> + (
> + cd empty_labels &&
> + echo base >file &&
> + git add file &&
> + git commit -m base &&
> + echo stashed >file &&
> + git stash push -m "stashed" &&
> + echo upstream >file &&
> + git add file &&
> + git commit -m upstream &&
> + test_must_fail git stash apply --ours-label= --theirs-label= &&
> + test_grep "^<<<<<<<$" file &&
> + test_grep "^>>>>>>>$" file
> + )
> +'
> +
> test_expect_success 'stash create reports a locked index' '
> test_when_finished "rm -rf repo" &&
> git init repo &&
> diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
> index 29dad98c49..659ad4ec97 100644
> --- a/xdiff/xmerge.c
> +++ b/xdiff/xmerge.c
> @@ -199,9 +199,9 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char *name1,
> int size, int i, int style,
> xdmerge_t *m, char *dest, int marker_size)
> {
> - int marker1_size = (name1 ? strlen(name1) + 1 : 0);
> - int marker2_size = (name2 ? strlen(name2) + 1 : 0);
> - int marker3_size = (name3 ? strlen(name3) + 1 : 0);
> + int marker1_size = (name1 && *name1 ? strlen(name1) + 1 : 0);
> + int marker2_size = (name2 && *name2 ? strlen(name2) + 1 : 0);
> + int marker3_size = (name3 && *name3 ? strlen(name3) + 1 : 0);
> int needs_cr = is_cr_needed(xe1, xe2, m);
>
> if (marker_size <= 0)
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-10 15:39 [PATCH v8 1/4] stash: add --ours-label, --theirs-label, --base-label for apply Phillip Wood
@ 2026-04-10 19:18 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-10 19:18 UTC (permalink / raw)
To: phillip.wood123; +Cc: git, gitgitgadget, haraldnordgren, phillip.wood
> This patch seems to be missing the implementation of these new options.
> Before submitting a patch series I find it is very helpful to run
>
> git rebase --keep-base -x make -x 'cd t && prove -j6 <tests that I
> think might fail>'
>
> to catch any mistakes.
Wow, that command is so powerful! Thanks for sharing that!
Will shift that definition to an earlier commit in my set.
> Why do we need to create a new repository just to stash some changes?
Isn't it good to do it in isolation, for when the test and/or its cleanup
fails. I tried to change it now, but it's not trivial, I quickly broke a
lot of subsequent tests.
> We have a helper test_commit() for creating commits (it is documented in
> t/test-lib-functions.sh)
Thanks, will update!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v8 4/4] checkout: -m (--merge) uses autostash when switching branches
@ 2026-04-09 23:49 Chris Torek
2026-04-10 14:38 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Chris Torek @ 2026-04-09 23:49 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Phillip Wood
On Thu, Apr 9, 2026 at 12:18 PM Harald Nordgren via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> ... If reapplying causes conflicts, the stash is
> kept and the user is told they can resolve and run "git stash drop",
> or run "git reset --hard" and later "git stash pop" to recover their
> changes.
I might suggest that this should recommend "git stash pop --index"
(either always, or if the stashed index differs from the stash's parent).
Chris
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v7 4/4] checkout: -m (--merge) uses autostash when switching branches
@ 2026-04-09 17:55 Junio C Hamano
2026-04-09 20:32 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-09 17:55 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Phillip Wood, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> === 3. Merge conflict
>
> -When a merge conflict happens during switching branches with
> -the `-m` option, you would see something like this:
> +When the `--merge` (`-m`) option is in effect and the locally
> +modified files overlap with files that need to be updated by the
> +branch switch, the changes are stashed and reapplied after the
> +switch. If the stash application results in conflicts, they are not
> +resolved and the stash is saved to the stash list:
"results in conflicts, they are not resolved" felt a bit funny thing
to say. The definition of resulting in conflicits is to be left
with unresolvable conflicts ;-), so ...
... and reapplied after the switch. If this process results in
conflicts, a stash entry is saved and made available in "git
stash list". This is so that you can revisit it in case if you
fail to resolve conflicts correctly.
or something. But reading what you have further down, I think the
last sentence "This is so that ..." is probably unnecessary.
> ...
> +Your local changes are stashed, however, applying it to carry
> +forward your local changes resulted in conflicts:
>
> + - You can try resolving them now. If you resolved them
> + successfully, discard the stash entry with "git stash drop".
>
> + - Alternatively you can "git reset --hard" if you do not want
> + to deal with them right now, and later "git stash pop" to
> + recover your local changes.
> ------------
> +
> +You can try resolving the conflicts now. Edit the conflicting files
> +and mark them resolved with `git add` as usual, then run `git stash
> +drop` to discard the stash entry. Alternatively, you can clear the
> +working tree with `git reset --hard` and recover your local changes
> +later with `git stash pop`.
Very well written. I am very happy to see this text.
> diff --git a/Documentation/git-switch.adoc b/Documentation/git-switch.adoc
> index 87707e9265..3147023dc3 100644
> --- a/Documentation/git-switch.adoc
> +++ b/Documentation/git-switch.adoc
> @@ -126,15 +126,16 @@ variable.
> If you have local modifications to one or more files that are
> different between the current branch and the branch to which
> you are switching, the command refuses to switch branches in
> + order to preserve your modifications in context. With this
> + option, the conflicting local changes are automatically
> + stashed before the switch and reapplied afterwards. If the
> + local changes do not overlap with the differences between
> + branches, the switch proceeds without stashing. If
> + reapplying the stash results in conflicts, the entry is
> + saved to the stash list. Resolve the conflicts and run
> + `git stash drop` when done, or clear the working tree
> + (e.g. with `git reset --hard`) before running `git stash pop`
> + later to re-apply your changes.
We lost "however" but it is OK.
We would want to hint that "The command refuses to" refers to the
default behaviour when option being described ("--merge") is not
given by some other means, which was what the "however" we lost from
the updated text was trying to do.
> @@ -217,15 +218,15 @@ $ git switch mytopic
> error: You have local changes to 'frotz'; not switching branches.
> ------------
>
> -You can give the `-m` flag to the command, which would try a three-way
> -merge:
> +You can give the `-m` flag to the command, which would carry your local
> +changes to the new branch:
Yes, saying "carry your local changes to" is much clearer than "try
a three-way merge". I very much like this new text.
> ------------
> $ git switch -m mytopic
> -Auto-merging frotz
> +Switched to branch 'mytopic'
> ------------
>
> -After this three-way merge, the local modifications are _not_
> +After the switch, the local modifications are reapplied and are _not_
> registered in your index file, so `git diff` would show you what
> changes you made since the tip of the new branch.
So now to the more exciting part. But there isn't much to comment
on, as it stayed the same since a previous iteration where Phillip's
excellent "we do not have to waste cycles to dry-run at all" idea.
> diff --git a/t/t7201-co.sh b/t/t7201-co.sh
> index 9bcf7c0b40..857a5a6bd1 100755
> --- a/t/t7201-co.sh
> +++ b/t/t7201-co.sh
> @@ -210,6 +210,194 @@ test_expect_success 'checkout --merge --conflict=diff3 <branch>' '
> test_cmp expect two
> '
>
> +test_expect_success 'checkout --merge --conflict=zdiff3 <branch>' '
> + git checkout -f main &&
> + git reset --hard &&
> + git clean -f &&
> +
> + fill a b X d e >two &&
> + git checkout --merge --conflict=zdiff3 simple &&
> +
> + cat <<-EOF >expect &&
> + a
> + <<<<<<< simple
> + c
> + ||||||| main
> + b
> + c
> + d
> + =======
> + b
> + X
> + d
> + >>>>>>> local
> + e
> + EOF
> + test_cmp expect two
> +'
OK. Do we want to verify with "git stash show -p" or something what
we stashed away? I see we later have an explicit test to see that
the stash entry can actually be used in "stash pop" after clearing
the stage with "checkout -f", so perhaps it is OK to leave it to
that test, instead of checking in every step.
> +test_expect_success 'checkout -m skips stash when no conflict' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 0 x y z >same &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + fill 0 x y z >expect &&
> + test_cmp expect same
> +'
This one may not just check "test_grep !" but also check the output
of "git stash list", perhaps take one before and after "checkout -m"
and compare them?
> +test_expect_success 'checkout -m stashes and applies on conflicting changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 6 7 >one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + test_grep "Applied autostash" actual &&
> + fill 1 2 3 4 5 6 7 >expect &&
> + test_cmp expect one
> +'
Nice.
> +test_expect_success 'checkout -m stashes on truly conflicting changes' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + test_must_fail git checkout side 2>stderr &&
> + test_grep "Your local changes" stderr &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep ! "Created autostash" actual &&
> + test_grep "resulted in conflicts" actual &&
> + test_grep "git stash drop" actual &&
> + git stash drop &&
> + git reset --hard
> +'
OK. This is an emulation of a user who gives up resolving and punts.
> +test_expect_success 'checkout -m produces usable stash on conflict' '
> + git checkout -f main &&
> + git clean -f &&
> +
> + fill 1 2 3 4 5 >one &&
> + git checkout -m side >actual 2>&1 &&
> + test_grep "recover your local changes" actual &&
> + git checkout -f main &&
> + git stash pop &&
> + fill 1 2 3 4 5 >expect &&
> + test_cmp expect one
> +'
Nice.
> +test_expect_success 'checkout -m applies stash cleanly with non-overlapping changes in same file' '
> + git checkout -f main &&
> + git reset --hard &&
> + git clean -f &&
> +
> + git checkout -b nonoverlap_base &&
> + fill a b c d >file &&
> + git add file &&
> + git commit -m "add file" &&
> +
> + git checkout -b nonoverlap_child &&
> + fill a b c INSERTED d >file &&
> + git commit -a -m "insert line near end of file" &&
> +
> + fill DIRTY a b c INSERTED d >file &&
> +
> + git checkout -m nonoverlap_base 2>stderr &&
> + test_grep "Applied autostash" stderr &&
> + test_grep ! "resulted in conflicts" stderr &&
> +
> + fill DIRTY a b c d >expect &&
> + test_cmp expect file &&
Should we or should we not see an extra stack entry saved at this point?
Don't we want to test it?
> +
> + git checkout -f main &&
> + git branch -D nonoverlap_base &&
> + git branch -D nonoverlap_child
> +'
Overall very nicely done.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH v7 3/4] sequencer: teach autostash apply to take optional conflict marker labels
@ 2026-04-09 17:32 Junio C Hamano
2026-04-09 21:20 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-09 17:32 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Phillip Wood, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Add label1, label2, and label_ancestor parameters to the autostash
> apply machinery so callers can pass custom conflict marker labels
> through to "git stash apply --ours-label/--theirs-label/--base-label".
> Introduce apply_autostash_ref_with_labels() for callers that want
> to pass labels.
It is just a naming thing, but the contrast between label[12] vs
label_ancestor feel a bit uneven. Wouldn't it make it easier to
grok a hunk like this, if you stick to ours/theirs/base terminlogy?
> + if (label1)
> + strvec_pushf(&child.args, "--ours-label=%s", label1);
> + if (label2)
> + strvec_pushf(&child.args, "--theirs-label=%s", label2);
> + if (label_ancestor)
> + strvec_pushf(&child.args, "--base-label=%s", label_ancestor);
Alternatively, if you prefer a conciseness of numbered names, it is
customary to use "1" for the common ancestor, "2" for ours, and "3"
for theirs, following the same model after how higher stage index
entries are used during a conflicting merge.
Other than that, this step is quite straight-forward and looking
good.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v7 1/4] stash: add --ours-label, --theirs-label, --base-label for apply
@ 2026-04-09 17:25 Junio C Hamano
2026-04-09 20:31 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-09 17:25 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Phillip Wood, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Allow callers of "git stash apply" to pass custom labels for conflict
> markers instead of the default "Updated upstream" and "Stashed changes".
> Document the new options and add a test.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> Documentation/git-stash.adoc | 11 ++++++++++-
> builtin/stash.c | 2 +-
> t/t3903-stash.sh | 18 ++++++++++++++++++
> 3 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-stash.adoc b/Documentation/git-stash.adoc
> index b05c990ecd..6829ba1140 100644
> --- a/Documentation/git-stash.adoc
> +++ b/Documentation/git-stash.adoc
> @@ -12,7 +12,7 @@ git stash list [<log-options>]
> git stash show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]
> git stash drop [-q | --quiet] [<stash>]
> git stash pop [--index] [-q | --quiet] [<stash>]
> -git stash apply [--index] [-q | --quiet] [<stash>]
> +git stash apply [--index] [-q | --quiet] [--ours-label=<label>] [--theirs-label=<label>] [--base-label=<label>] [<stash>]
> git stash branch <branchname> [<stash>]
> git stash [push] [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
> [-u | --include-untracked] [-a | --all] [(-m | --message) <message>]
> @@ -195,6 +195,15 @@ the index's ones. However, this can fail, when you have conflicts
> (which are stored in the index, where you therefore can no longer
> apply the changes as they were originally).
>
> +`--ours-label=<label>`::
> +`--theirs-label=<label>`::
> +`--base-label=<label>`::
> + These options are only valid for the `apply` command.
> ++
> +Use the given labels in conflict markers instead of the default
> +"Updated upstream", "Stashed changes", and "Stash base".
> +`--base-label` only has an effect with merge.conflictStyle=diff3.
> +
> `-k`::
> `--keep-index`::
> `--no-keep-index`::
> diff --git a/builtin/stash.c b/builtin/stash.c
> index 0d27b2fb1f..54bcb6ac73 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -44,7 +44,7 @@
> #define BUILTIN_STASH_POP_USAGE \
> N_("git stash pop [--index] [-q | --quiet] [<stash>]")
> #define BUILTIN_STASH_APPLY_USAGE \
> - N_("git stash apply [--index] [-q | --quiet] [<stash>]")
> + N_("git stash apply [--index] [-q | --quiet] [--ours-label=<label>] [--theirs-label=<label>] [--base-label=<label>] [<stash>]")
> #define BUILTIN_STASH_BRANCH_USAGE \
> N_("git stash branch <branchname> [<stash>]")
> #define BUILTIN_STASH_STORE_USAGE \
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 70879941c2..dd47c1322a 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -1666,6 +1666,24 @@ test_expect_success 'restore untracked files even when we hit conflicts' '
> )
> '
>
> +test_expect_success 'apply with custom conflict labels' '
> + git init conflict_labels &&
> + (
> + cd conflict_labels &&
> + echo base >file &&
> + git add file &&
> + git commit -m base &&
> + echo stashed >file &&
> + git stash push -m "stashed" &&
> + echo upstream >file &&
> + git add file &&
> + git commit -m upstream &&
> + test_must_fail git stash apply --ours-label=UP --theirs-label=STASH &&
> + grep "^<<<<<<< UP" file &&
> + grep "^>>>>>>> STASH" file
> + )
> +'
Two and a half things I noticed.
* use "test_grep" to validate the result, like you did in other
patches to the tests. t3903 is rather old and has uses of raw
"grep" but majority of the tests should already be using
test_grep.
* Not validating the base line is a bit unexpected. Even without
giving --base-label to the "stash apply" command, we could make
sure that the output says "|||||||" (and nothing else) for the
base label.
* When these labels are set to an empty string, I think we should
refrain from adding a trailing " " after these marker characters.
Should we add a test case for that, e.g.
test_must_fail git stash apply --ours-l= --theirs-l= &&
test_grep "^<<<<<<<$" file &&
test_grep "^>>>>>>>$" file
> test_expect_success 'stash create reports a locked index' '
> test_when_finished "rm -rf repo" &&
> git init repo &&
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-09 17:25 [PATCH v7 1/4] stash: add --ours-label, --theirs-label, --base-label for apply Junio C Hamano
@ 2026-04-09 20:31 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-09 20:31 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren, phillip.wood123
> Two and a half things I noticed.
>
> * use "test_grep" to validate the result, like you did in other
> patches to the tests. t3903 is rather old and has uses of raw
> "grep" but majority of the tests should already be using
> test_grep.
>
> * Not validating the base line is a bit unexpected. Even without
> giving --base-label to the "stash apply" command, we could make
> sure that the output says "|||||||" (and nothing else) for the
> base label.
>
> * When these labels are set to an empty string, I think we should
> refrain from adding a trailing " " after these marker characters.
> Should we add a test case for that, e.g.
>
> test_must_fail git stash apply --ours-l= --theirs-l= &&
> test_grep "^<<<<<<<$" file &&
> test_grep "^>>>>>>>$" file
Fixed, thanks!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v7 0/4] checkout: 'autostash' for branch switching
@ 2026-04-09 17:00 Junio C Hamano
2026-04-09 21:23 ` [PATCH] checkout: add --autostash option " Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-09 17:00 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Phillip Wood, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Harald Nordgren (4):
> stash: add --ours-label, --theirs-label, --base-label for apply
> sequencer: allow create_autostash to run silently
> sequencer: teach autostash apply to take optional conflict marker
> labels
> checkout: -m (--merge) uses autostash when switching branches
Thanks for an update. Above the list of the commits, it would be
helpful to give a summary of the overall goal of the topic (which
typically stays more or less the same during the life of the topic)
and the highlights of the changes since the previous iteration
(which authors often accumulate, so that in a cover letter for v7,
there will be 6 such summaries), if you are sending a cover letter.
I _think_ the change since v6 is a rebasing onto a more recent
'master', and addition of a new test?
Thanks.
> Documentation/git-checkout.adoc | 58 +++++-----
> Documentation/git-stash.adoc | 11 +-
> Documentation/git-switch.adoc | 27 ++---
> builtin/checkout.c | 138 ++++++++++-------------
> builtin/stash.c | 32 ++++--
> sequencer.c | 67 +++++++++---
> sequencer.h | 4 +
> t/t3420-rebase-autostash.sh | 24 +++-
> t/t3903-stash.sh | 18 +++
> t/t7201-co.sh | 188 ++++++++++++++++++++++++++++++++
> t/t7600-merge.sh | 2 +-
> xdiff-interface.c | 12 ++
> xdiff-interface.h | 1 +
> 13 files changed, 431 insertions(+), 151 deletions(-)
>
>
> base-commit: b15384c06f77bc2d34d0d3623a8a58218313a561
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2234%2FHaraldNordgren%2Fcheckout_autostash-v7
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2234/HaraldNordgren/checkout_autostash-v7
> Pull-Request: https://github.com/git/git/pull/2234
>
> Range-diff vs v6:
>
> 1: cd9c64ba60 ! 1: 284075600a stash: add --ours-label, --theirs-label, --base-label for apply
> @@ Documentation/git-stash.adoc: git stash list [<log-options>]
> -git stash apply [--index] [-q | --quiet] [<stash>]
> +git stash apply [--index] [-q | --quiet] [--ours-label=<label>] [--theirs-label=<label>] [--base-label=<label>] [<stash>]
> git stash branch <branchname> [<stash>]
> - git stash [push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
> + git stash [push] [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
> [-u | --include-untracked] [-a | --all] [(-m | --message) <message>]
> @@ Documentation/git-stash.adoc: the index's ones. However, this can fail, when you have conflicts
> (which are stored in the index, where you therefore can no longer
> 2: d572c4bb7d = 2: 64261e3cb6 sequencer: allow create_autostash to run silently
> 3: 80a98116fc = 3: c0d6b4b4c0 sequencer: teach autostash apply to take optional conflict marker labels
> 4: 7ecb0835b7 ! 4: 1c29e19971 checkout: -m (--merge) uses autostash when switching branches
> @@ builtin/checkout.c: static int merge_working_tree(const struct checkout_opts *op
> - 0, 0);
> - init_ui_merge_options(&o, the_repository);
> - o.verbosity = 0;
> -- work = write_in_core_index_as_tree(the_repository);
> +- work = write_in_core_index_as_tree(the_repository,
> +- the_repository->index);
> -
> - ret = reset_tree(new_tree,
> - opts, 1,
> @@ t/t7201-co.sh: test_expect_success 'checkout --merge --conflict=diff3 <branch>'
> + git reset --hard
> +'
> +
> ++test_expect_success 'checkout -m applies stash cleanly with non-overlapping changes in same file' '
> ++ git checkout -f main &&
> ++ git reset --hard &&
> ++ git clean -f &&
> ++
> ++ git checkout -b nonoverlap_base &&
> ++ fill a b c d >file &&
> ++ git add file &&
> ++ git commit -m "add file" &&
> ++
> ++ git checkout -b nonoverlap_child &&
> ++ fill a b c INSERTED d >file &&
> ++ git commit -a -m "insert line near end of file" &&
> ++
> ++ fill DIRTY a b c INSERTED d >file &&
> ++
> ++ git checkout -m nonoverlap_base 2>stderr &&
> ++ test_grep "Applied autostash" stderr &&
> ++ test_grep ! "resulted in conflicts" stderr &&
> ++
> ++ fill DIRTY a b c d >expect &&
> ++ test_cmp expect file &&
> ++
> ++ git checkout -f main &&
> ++ git branch -D nonoverlap_base &&
> ++ git branch -D nonoverlap_child
> ++'
> ++
> +test_expect_success 'checkout -m -b skips stash with dirty tree' '
> + git checkout -f main &&
> + git clean -f &&
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-09 17:00 [PATCH v7 0/4] checkout: 'autostash' " Junio C Hamano
@ 2026-04-09 21:23 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-09 21:23 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren, phillip.wood123
> Thanks for an update. Above the list of the commits, it would be
> helpful to give a summary of the overall goal of the topic (which
> typically stays more or less the same during the life of the topic)
> and the highlights of the changes since the previous iteration
> (which authors often accumulate, so that in a cover letter for v7,
> there will be 6 such summaries), if you are sending a cover letter.
I'm not exactly sure how to do that with GitGitGadget.
Isn't that what the commit message of the only non-preperatory commit is
here?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v3] checkout: add --autostash option for branch switching
@ 2026-03-13 17:16 Junio C Hamano
2026-03-13 19:33 ` [PATCH] " Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-13 17:16 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When switching branches, local modifications in the working tree can
> prevent the checkout from succeeding. While "git rebase" and "git
> merge" already support --autostash to handle this case automatically,
> "git checkout" and "git switch" require users to manually stash and
> unstash their changes.
>
> Teach "git checkout" and "git switch" to accept --autostash and
> --no-autostash options that automatically create a temporary stash
> entry before the branch switch begins and apply it after the switch
> completes. If the stash application results in conflicts, the stash
> entry is saved to the stash list so the user can resolve them later.
>
> Also add a checkout.autoStash configuration option that enables this
> behavior by default, which can be overridden with --no-autostash on
> the command line.
>
> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
> checkout: 'autostash' for branch switching
Almost all of the above is now stale, as we no longer call this the
"autostash" feature. It turned into a project to vastly improve the
"checkout --merge" option, so the proposed log message needs to be
revamped to match.
Using the autostash mechanism to simplify checkout.c is a great
direction, I think, provided we can maintain the high-quality
conflict information (branch labels) that users expect from '-m'.
For a new iteration that invalidates almost everything from the
previous round, it is easier if range-diff were omitted from the
reviewers' point of view (I am not a GGG user, so I do not know if
there is such an option to do so). It is not a huge deal as we can
simply ignore the large block of lines as irrelevant ;-)
> Documentation/git-checkout.adoc | 50 +++++-----
> Documentation/git-switch.adoc | 26 ++---
> builtin/checkout.c | 160 +++++++++++++++---------------
> sequencer.c | 2 +-
> t/t7201-co.sh | 170 +++++++++++++++++++++++++++++++-
> xdiff-interface.c | 12 +++
> xdiff-interface.h | 1 +
> 7 files changed, 293 insertions(+), 128 deletions(-)
>
> diff --git a/Documentation/git-checkout.adoc b/Documentation/git-checkout.adoc
> index 43ccf47cf6..1e8adf6ef3 100644
> --- a/Documentation/git-checkout.adoc
> +++ b/Documentation/git-checkout.adoc
> @@ -251,20 +251,17 @@ working tree, by copying them from elsewhere, extracting a tarball, etc.
> are different between the current branch and the branch to
> which you are switching, the command refuses to switch
> branches in order to preserve your modifications in context.
> + With this option, the conflicting local changes are
> + automatically stashed before the switch and reapplied
> + afterwards. If the local changes do not overlap with the
> + differences between branches, the switch proceeds without
> + stashing. If reapplying the stash results in conflicts, the
> + entry is saved to the stash list so you can use `git stash
> + pop` to recover and `git stash drop` when done.
Great.
> -+
> -When switching branches with `--merge`, staged changes may be lost.
Hmph, I have to admit that I never do "checkout" to go to a different
branch with a dirty index that does not match the current HEAD, with
or without "--merge"; in fact, not just "I never do" myself, I never
thought about what happens when somebody does so, so I do not offhand
know what the current code without this patch does, or what the updated
code would. In "stash && switch && unstash" flow, the last "unstash"
is what decides if the original changes in the index is reapplied to
the index or not, IIRC, so we still may lose the distinction between
what has been and what has not been added to the index after all,
depending on the way how the new code does the "unstash" step.
> @@ -578,39 +575,36 @@ $ git checkout mytopic
> error: You have local changes to 'frotz'; not switching branches.
> ------------
>
> -You can give the `-m` flag to the command, which would try a
> -three-way merge:
> +You can give the `-m` flag to the command, which would save the local
> +changes in a stash entry and reset the working tree to allow switching:
>
> ------------
> $ git checkout -m mytopic
> -Auto-merging frotz
> +Created autostash: 7a9afa3
> +Applied autostash.
> ------------
>
> -After this three-way merge, the local modifications are _not_
> +After the switch, the local modifications are reapplied and are _not_
> registered in your index file, so `git diff` would show you what
> changes you made since the tip of the new branch.
OK.
> === 3. Merge conflict
>
> -When a merge conflict happens during switching branches with
> -the `-m` option, you would see something like this:
> +When the locally modified files overlap with files that need to be
> +updated by the branch switch, the changes are stashed and reapplied
> +after the switch. If the stash application results in conflicts,
In the original text of this third example (and as I understand,
these examples are written to be read more-or-less independently),
the `-m` option was explicitly mentioned to make it clear that this
"conflict" situation is relevant only when the option is used. In
the updated text, it is not. We should mention `-m` somewhere in
the updated text as well: When the `--merge` (`-m`) option is in
effect, _this_ happens.
> +they are not resolved and the stash is saved to the stash list:
>
> ------------
> $ git checkout -m mytopic
> -Auto-merging frotz
> -ERROR: Merge conflict in frotz
> -fatal: merge program failed
> +Created autostash: 7a9afa3
> +Applying autostash resulted in conflicts.
> +Your changes are safe in the stash.
> +You can run "git stash pop" or "git stash drop" at any time.
> ------------
Nice. It may probably be on a bit too verbose side, though. The
fact we are creating a stash entry or the object name of it is not
interesting to the user unless there is a conflict, so I would have
thought we would not say "Created autostash" at all, and the last
three lines would be replaced with something like the following
and shown _only_ when the application of the stashed changes did not
succeed cleanly:
Your local changes are stashed, however, applying it to carry
forward your local changes resulted in conflicts:
- You can try resolving them now. If you resolved them
successfully, discard the stash entry with "git stash drop".
- Alternatively you can "git reset --hard" if you do not want
to deal with them right now, and later "git stash pop" to
recover your local changes.
> -At this point, `git diff` shows the changes cleanly merged as in
> -the previous example, as well as the changes in the conflicted
> -files. Edit and resolve the conflict and mark it resolved with
> -`git add` as usual:
> -
> -------------
> -$ edit frotz
> -$ git add frotz
> -------------
After resolving and adding, they need to do "git stash drop" it, but
other than that, this part of the example is still valid, isn't it?
The improvement this patch brings in is that the user now has
another choice, i.e.,
Instead of editing and resolving the conflicts right now, you
can clear the slate with `git reset --hard` and resurrect the
local changes, safely stored in the stash at your leisure, with
`git stash pop`.
> +At this point, `git stash pop` can be used to recover and resolve
> +the conflicts, and `git stash drop` to discard the stash when done.
This is not giving a wrong instruction per-se, but my suggestion
above can be used to extend it if we wanted to. It may make it
easier to understand to the readers, or it may make it way too
verbose. I dunno.
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 1d1667fa4c..d3b3b815a7 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -17,7 +17,6 @@
> #include "merge-ll.h"
> #include "lockfile.h"
> #include "mem-pool.h"
> -#include "merge-ort-wrappers.h"
> #include "object-file.h"
> #include "object-name.h"
> #include "odb.h"
> @@ -30,6 +29,7 @@
> #include "repo-settings.h"
> #include "resolve-undo.h"
> #include "revision.h"
> +#include "sequencer.h"
> #include "setup.h"
> #include "submodule.h"
> #include "symlinks.h"
> @@ -845,83 +845,8 @@ static int merge_working_tree(const struct checkout_opts *opts,
>
> ret = unpack_trees(2, trees, &topts);
> clear_unpack_trees_porcelain(&topts);
> - if (ret == -1) {
> - /*
> - * Unpack couldn't do a trivial merge; either
> - * give up or do a real merge, depending on
> - * whether the merge flag was used.
> - */
> -...
> - }
> + if (ret == -1)
> + return 1;
> }
So pleased to see so much custom code getting removed ;-).
> diff --git a/sequencer.c b/sequencer.c
> index aafd0bc959..72f0afe609 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -4677,7 +4677,7 @@ static void create_autostash_internal(struct repository *r,
> &oid, null_oid(the_hash_algo), 0, UPDATE_REFS_DIE_ON_ERR);
> }
>
> - printf(_("Created autostash: %s\n"), buf.buf);
> + fprintf(stderr, _("Created autostash: %s\n"), buf.buf);
> if (reset_head(r, &ropts) < 0)
> die(_("could not reset --hard"));
> discard_index(r->index);
Is this change something all the callers that passes control through
this part desire? Don't some of them want the output go to the
standard output, not standard error?
If we are going in the direction I suggested above (i.e., be silent
about our use of stashes before it becomes relevant to the user),
this part may have to become a conditional
if (!silent)
printf(_("Created autostash: %s\n"), buf.buf);
or something, where all the current callers before the "checkout
--merge" adds a new caller would pass silent==0 to.
Whatever changes this function needs, it looks more like a separate
preparatory patch to me.
> diff --git a/t/t7201-co.sh b/t/t7201-co.sh
> index 9bcf7c0b40..9ace3962ba 100755
> --- a/t/t7201-co.sh
> +++ b/t/t7201-co.sh
> @@ -171,14 +171,14 @@ test_expect_success 'format of merge conflict from checkout -m' '
> test_cmp expect current &&
>
> cat <<-EOF >expect &&
> - <<<<<<< simple
> + <<<<<<< Updated upstream
> a
> c
> e
> =======
> b
> d
> - >>>>>>> local
> + >>>>>>> Stashed changes
> EOF
> test_cmp expect two
> '
Historically, 'git checkout -m' provided the branch names (e.g.,
"<<<<<<< simple"), which is very helpful context. It would be great
if we could find a way to pass the branch names through as labels to
the stash application. It may require a preparatory change to "git
stash apply" to allow customizing the labels---the underlying
machinery at the lowest level does have ability to use labels the
callers want it to use, so it may be just the matter of plumbing it
through the callchain. I didn't check.
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index f043330f2a..5ee2b96d0a 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -325,6 +325,18 @@ int parse_conflict_style_name(const char *value)
> return -1;
> }
>
> +const char *conflict_style_name(int style)
> +{
> + switch (style) {
> + case XDL_MERGE_DIFF3:
> + return "diff3";
> + case XDL_MERGE_ZEALOUS_DIFF3:
> + return "zdiff3";
> + default:
> + return "merge";
> + }
> +}
> +
> int git_xmerge_style = -1;
>
> int git_xmerge_config(const char *var, const char *value,
> diff --git a/xdiff-interface.h b/xdiff-interface.h
> index fbc4ceec40..ce54e1c0e0 100644
> --- a/xdiff-interface.h
> +++ b/xdiff-interface.h
> @@ -55,6 +55,7 @@ void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line, int cflags);
> void xdiff_clear_find_func(xdemitconf_t *xecfg);
> struct config_context;
> int parse_conflict_style_name(const char *value);
> +const char *conflict_style_name(int style);
> int git_xmerge_config(const char *var, const char *value,
> const struct config_context *ctx, void *cb);
> extern int git_xmerge_style;
This may be a useful addition, but it would probably need to become
a separate preparatory patch, possibly with its own test.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-13 17:16 [PATCH v3] " Junio C Hamano
@ 2026-03-13 19:33 ` Harald Nordgren
2026-03-13 20:30 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-03-13 19:33 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren
> Almost all of the above is now stale, as we no longer call this the
> "autostash" feature. It turned into a project to vastly improve the
> "checkout --merge" option, so the proposed log message needs to be
> revamped to match.
My feeling is that this feature will drift far away from what I initially
needed. I have never used 'checkout -m' but stash->checkout-unstash is a
pattern I use a lot.
I wonder with how complicated this might turn out, if it would be better to
have this as a separate feature called autostash (mirroring the same
feature from git pull rebase which I have enabled).
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-13 19:33 ` [PATCH] " Harald Nordgren
@ 2026-03-13 20:30 ` Junio C Hamano
0 siblings, 0 replies; 69+ messages in thread
From: Junio C Hamano @ 2026-03-13 20:30 UTC (permalink / raw)
To: Harald Nordgren; +Cc: git, gitgitgadget
Harald Nordgren <haraldnordgren@gmail.com> writes:
>> Almost all of the above is now stale, as we no longer call this the
>> "autostash" feature. It turned into a project to vastly improve the
>> "checkout --merge" option, so the proposed log message needs to be
>> revamped to match.
>
> My feeling is that this feature will drift far away from what I initially
> needed. I have never used 'checkout -m' but stash->checkout-unstash is a
> pattern I use a lot.
Perhaps. But things like "checkout --autostash", which can entirely
be done by the end user via a wrapper script or an alias, is not
interesting enough from my point of view.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH v2] checkout: add --autostash option for branch switching
@ 2026-03-12 19:50 Junio C Hamano
2026-03-13 9:22 ` [PATCH] " Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-12 19:50 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When switching branches, local modifications in the working tree can
> prevent the checkout from succeeding. While "git rebase" and "git
> merge" already support --autostash to handle this case automatically,
> "git checkout" and "git switch" require users to manually stash and
> unstash their changes.
>
> Teach "git checkout" and "git switch" to accept --autostash and
> --no-autostash options that automatically create a temporary stash
> entry before the branch switch begins and apply it after the switch
> completes. If the stash application results in conflicts, the stash
> entry is saved to the stash list so the user can resolve them later.
>
> Also add a checkout.autoStash configuration option that enables this
> behavior by default, which can be overridden with --no-autostash on
> the command line.
With this, shouldn't "-m" become a synonym for "--autostash"?
For users of "checkout -m", this is a strictly improved version of
the same feature, it seems.
Also, "stash" is merely an implementation detail of how we make the
merge safer, so from end-user's point of view, this feature is more
like "switch to the other branch, while merging the local changes
there", so calling it "--merge" or something may be much better than
calling it "--autostash".
Other than that, I like the implementation in general.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-12 19:50 [PATCH v2] " Junio C Hamano
@ 2026-03-13 9:22 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-03-13 9:22 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren
> With this, shouldn't "-m" become a synonym for "--autostash"?
> For users of "checkout -m", this is a strictly improved version of
> the same feature, it seems.
>
> Also, "stash" is merely an implementation detail of how we make the
> merge safer, so from end-user's point of view, this feature is more
> like "switch to the other branch, while merging the local changes
> there", so calling it "--merge" or something may be much better than
> calling it "--autostash".
That's an interesting idea and I gave it a shot! I do worry about breaking
the existing '-m' flow because I don't understand its fundamentals.
But tests old seem to be passing (well, they did break and then I fixed the
code to make them pass again), so that's promising. Although hard for me to
say if the old test coverage protects against all possible regressions.
> Other than that, I like the implementation in general.
Thanks for all your support, Junio!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* [PATCH] checkout: add --autostash option for branch switching
@ 2026-03-12 13:26 Harald Nordgren via GitGitGadget
2026-03-12 14:40 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren via GitGitGadget @ 2026-03-12 13:26 UTC (permalink / raw)
To: git; +Cc: Harald Nordgren, Harald Nordgren
From: Harald Nordgren <haraldnordgren@gmail.com>
When switching branches, local modifications in the working tree can
prevent the checkout from succeeding. While "git rebase" and "git
merge" already support --autostash to handle this case automatically,
"git checkout" and "git switch" require users to manually stash and
unstash their changes.
Teach "git checkout" and "git switch" to accept --autostash and
--no-autostash options that automatically create a temporary stash
entry before the branch switch begins and apply it after the switch
completes. If the stash application results in conflicts, the stash
entry is saved to the stash list so the user can resolve them later.
Also add a checkout.autoStash configuration option that enables this
behavior by default, which can be overridden with --no-autostash on
the command line.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
checkout: 'autostash' for branch switching
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2234%2FHaraldNordgren%2Fcheckout_autostash-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2234/HaraldNordgren/checkout_autostash-v1
Pull-Request: https://github.com/git/git/pull/2234
Documentation/config/checkout.adoc | 12 ++
Documentation/git-checkout.adoc | 9 ++
Documentation/git-switch.adoc | 9 ++
builtin/checkout.c | 16 +++
t/meson.build | 1 +
t/t2061-switch-autostash.sh | 181 +++++++++++++++++++++++++++++
t/t9902-completion.sh | 1 +
7 files changed, 229 insertions(+)
create mode 100755 t/t2061-switch-autostash.sh
diff --git a/Documentation/config/checkout.adoc b/Documentation/config/checkout.adoc
index e35d212969..2e157c5398 100644
--- a/Documentation/config/checkout.adoc
+++ b/Documentation/config/checkout.adoc
@@ -36,6 +36,18 @@ with a small number of cores, the default sequential checkout often performs
better. The size and compression level of a repository might also influence how
well the parallel version performs.
+`checkout.autoStash`::
+ When set to true, automatically create a temporary stash entry
+ before the operation begins, and apply it after the operation
+ ends. This means that you can run `git checkout` or `git switch`
+ on a dirty worktree. However, use with care: the final stash
+ application after a successful branch switch might result in
+ non-trivial conflicts.
+ This option can be overridden by the `--no-autostash` and
+ `--autostash` options of linkgit:git-checkout[1] and
+ linkgit:git-switch[1].
+ Defaults to false.
+
`checkout.thresholdForParallelism`::
When running parallel checkout with a small number of files, the cost
of subprocess spawning and inter-process communication might outweigh
diff --git a/Documentation/git-checkout.adoc b/Documentation/git-checkout.adoc
index 43ccf47cf6..96d9bf9203 100644
--- a/Documentation/git-checkout.adoc
+++ b/Documentation/git-checkout.adoc
@@ -272,6 +272,15 @@ When switching branches with `--merge`, staged changes may be lost.
`merge.conflictStyle` configuration variable. Possible values are
`merge` (default), `diff3`, and `zdiff3`.
+`--autostash`::
+`--no-autostash`::
+ When switching branches, automatically create a temporary stash
+ entry before the operation begins, and apply it after the
+ operation ends. This means that you can switch branches on a
+ dirty worktree. However, use with care: the final stash
+ application after a successful branch switch might result in
+ non-trivial conflicts.
+
`-p`::
`--patch`::
Interactively select hunks in the difference between the
diff --git a/Documentation/git-switch.adoc b/Documentation/git-switch.adoc
index 87707e9265..b296df2a0b 100644
--- a/Documentation/git-switch.adoc
+++ b/Documentation/git-switch.adoc
@@ -142,6 +142,15 @@ should result in deletion of the path).
`merge.conflictStyle` configuration variable. Possible values are
`merge` (default), `diff3`, and `zdiff3`.
+`--autostash`::
+`--no-autostash`::
+ Automatically create a temporary stash entry before the
+ operation begins, and apply it after the operation ends.
+ This means that you can switch branches on a dirty worktree.
+ However, use with care: the final stash application after a
+ successful branch switch might result in non-trivial
+ conflicts.
+
`-q`::
`--quiet`::
Quiet, suppress feedback messages.
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 1d1667fa4c..453dbe3230 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -30,6 +30,7 @@
#include "repo-settings.h"
#include "resolve-undo.h"
#include "revision.h"
+#include "sequencer.h"
#include "setup.h"
#include "submodule.h"
#include "symlinks.h"
@@ -68,6 +69,7 @@ struct checkout_opts {
int only_merge_on_switching_branches;
int can_switch_when_in_progress;
int orphan_from_empty_tree;
+ int autostash;
int empty_pathspec_ok;
int checkout_index;
int checkout_worktree;
@@ -1202,9 +1204,16 @@ static int switch_branches(const struct checkout_opts *opts,
do_merge = 0;
}
+ if (opts->autostash) {
+ if (repo_read_index(the_repository) < 0)
+ die(_("index file corrupt"));
+ create_autostash_ref(the_repository, "CHECKOUT_AUTOSTASH");
+ }
+
if (do_merge) {
ret = merge_working_tree(opts, &old_branch_info, new_branch_info, &writeout_error);
if (ret) {
+ apply_autostash_ref(the_repository, "CHECKOUT_AUTOSTASH");
branch_info_release(&old_branch_info);
return ret;
}
@@ -1215,6 +1224,8 @@ static int switch_branches(const struct checkout_opts *opts,
update_refs_for_switch(opts, &old_branch_info, new_branch_info);
+ apply_autostash_ref(the_repository, "CHECKOUT_AUTOSTASH");
+
ret = post_checkout_hook(old_branch_info.commit, new_branch_info->commit, 1);
branch_info_release(&old_branch_info);
@@ -1236,6 +1247,10 @@ static int git_checkout_config(const char *var, const char *value,
opts->dwim_new_local_branch = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, "checkout.autostash")) {
+ opts->autostash = git_config_bool(var, value);
+ return 0;
+ }
if (starts_with(var, "submodule."))
return git_default_submodule_config(var, value, NULL);
@@ -1745,6 +1760,7 @@ static struct option *add_common_switch_branch_options(
PARSE_OPT_NOCOMPLETE),
OPT_BOOL(0, "ignore-other-worktrees", &opts->ignore_other_worktrees,
N_("do not check if another worktree is using this branch")),
+ OPT_AUTOSTASH(&opts->autostash),
OPT_END()
};
struct option *newopts = parse_options_concat(prevopts, options);
diff --git a/t/meson.build b/t/meson.build
index f66a73f8a0..0645253d25 100644
--- a/t/meson.build
+++ b/t/meson.build
@@ -275,6 +275,7 @@ integration_tests = [
't2030-unresolve-info.sh',
't2050-git-dir-relative.sh',
't2060-switch.sh',
+ 't2061-switch-autostash.sh',
't2070-restore.sh',
't2071-restore-patch.sh',
't2072-restore-pathspec-file.sh',
diff --git a/t/t2061-switch-autostash.sh b/t/t2061-switch-autostash.sh
new file mode 100755
index 0000000000..6409a2afbf
--- /dev/null
+++ b/t/t2061-switch-autostash.sh
@@ -0,0 +1,181 @@
+#!/bin/sh
+
+test_description='checkout/switch --autostash tests'
+
+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo file0content >file0 &&
+ echo file1content >file1 &&
+ git add . &&
+ test_tick &&
+ git commit -m "initial commit" &&
+ git branch other-branch &&
+ echo file1main >file1 &&
+ git add . &&
+ test_tick &&
+ git commit -m "modify file1 on main" &&
+ git checkout other-branch &&
+ echo file1other >file1 &&
+ git add . &&
+ test_tick &&
+ git commit -m "modify file1 on other-branch" &&
+ echo file2content >file2 &&
+ git add . &&
+ test_tick &&
+ git commit -m "add file2 on other-branch" &&
+ git checkout main
+'
+
+test_expect_success 'switch --autostash on dirty worktree' '
+ git branch branch1 other-branch &&
+ echo dirty >file0 &&
+ git switch --autostash branch1 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git switch main
+'
+
+test_expect_success 'checkout --autostash on dirty worktree' '
+ git branch branch2 other-branch &&
+ echo dirty >file0 &&
+ git checkout --autostash branch2 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git checkout main
+'
+
+test_expect_success 'switch: checkout.autostash config' '
+ git branch branch3 other-branch &&
+ echo dirty >file0 &&
+ test_config checkout.autostash true &&
+ git switch branch3 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git switch main
+'
+
+test_expect_success 'checkout: checkout.autostash config' '
+ git branch branch4 other-branch &&
+ echo dirty >file0 &&
+ test_config checkout.autostash true &&
+ git checkout branch4 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git checkout main
+'
+
+test_expect_success '--no-autostash overrides checkout.autostash' '
+ git branch branch5 other-branch &&
+ echo dirty >file1 &&
+ test_config checkout.autostash true &&
+ test_must_fail git switch --no-autostash branch5 2>stderr &&
+ test_grep ! "Created autostash" stderr &&
+ git checkout -- file1
+'
+
+test_expect_success '--autostash overrides checkout.autostash=false' '
+ git branch branch6 other-branch &&
+ echo dirty >file0 &&
+ test_config checkout.autostash false &&
+ git switch --autostash branch6 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git switch main
+'
+
+test_expect_success 'autostash with dirty index' '
+ git branch branch7 other-branch &&
+ echo dirty-index >file0 &&
+ git add file0 &&
+ git switch --autostash branch7 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty-index >expected &&
+ test_cmp expected file0 &&
+ git checkout -- file0 &&
+ git switch main
+'
+
+test_expect_success 'autostash bypasses conflicting local changes' '
+ git branch branch8 other-branch &&
+ echo dirty >file1 &&
+ test_must_fail git switch branch8 2>stderr &&
+ test_grep "Your local changes" stderr &&
+ git switch --autostash branch8 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applying autostash resulted in conflicts" actual &&
+ test_grep "Your changes are safe in the stash" actual &&
+ git stash drop &&
+ git reset --hard &&
+ git switch main
+'
+
+test_expect_success 'autostash is a no-op with clean worktree' '
+ git branch branch9 other-branch &&
+ git switch --autostash branch9 >actual 2>&1 &&
+ test_grep ! "Created autostash" actual &&
+ git switch main
+'
+
+test_expect_success '--autostash with --merge stashes and switches' '
+ git branch branch10 other-branch &&
+ echo dirty >file0 &&
+ git switch --autostash --merge branch10 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git switch main
+'
+
+test_expect_success 'autostash with staged conflicting changes' '
+ git branch branch11 other-branch &&
+ echo staged-change >file1 &&
+ git add file1 &&
+ git switch --autostash branch11 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applying autostash resulted in conflicts" actual &&
+ test_grep "Your changes are safe in the stash" actual &&
+ git stash drop &&
+ git reset --hard &&
+ git switch main
+'
+
+test_expect_success '--autostash with --force preserves dirty changes' '
+ git branch branch12 other-branch &&
+ echo dirty-force >file1 &&
+ git switch --autostash --force branch12 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applying autostash resulted in conflicts" actual &&
+ test_grep "Your changes are safe in the stash" actual &&
+ git stash drop &&
+ git reset --hard &&
+ git switch main
+'
+
+test_expect_success '--autostash with new branch creation' '
+ echo dirty >file0 &&
+ git switch --autostash -c branch13 >actual 2>&1 &&
+ test_grep "Created autostash" actual &&
+ test_grep "Applied autostash" actual &&
+ echo dirty >expected &&
+ test_cmp expected file0 &&
+ git switch main &&
+ git branch -D branch13
+'
+
+test_done
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 2f9a597ec7..f33ca543a9 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -2602,6 +2602,7 @@ test_expect_success 'double dash "git checkout"' '
--ignore-other-worktrees Z
--recurse-submodules Z
--auto-advance Z
+ --autostash Z
--progress Z
--guess Z
--no-guess Z
base-commit: 7f19e4e1b6a3ad259e2ed66033e01e03b8b74c5e
--
gitgitgadget
^ permalink raw reply related [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-12 13:26 Harald Nordgren via GitGitGadget
@ 2026-03-12 14:40 ` Junio C Hamano
2026-03-13 14:29 ` Phillip Wood
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-12 14:40 UTC (permalink / raw)
To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When switching branches, local modifications in the working tree can
> prevent the checkout from succeeding. While "git rebase" and "git
> merge" already support --autostash to handle this case automatically,
> "git checkout" and "git switch" require users to manually stash and
> unstash their changes.
>
> Teach "git checkout" and "git switch" to accept --autostash and
> --no-autostash options that automatically create a temporary stash
> entry before the branch switch begins and apply it after the switch
> completes. If the stash application results in conflicts, the stash
> entry is saved to the stash list so the user can resolve them later.
>
> Also add a checkout.autoStash configuration option that enables this
> behavior by default, which can be overridden with --no-autostash on
> the command line.
Unconditionally always stash when checkout happens? This feature as
implemented does not have to be a separate feature. It can be done
by end-users as a short-cut for "stash" followed by "checkout" via
alias or custom command.
Perhaps doing it this way would make it more worth doing?
- At the beginning of branch switching, ask a new helper function
that takes the branch we are switching to as an argument this
question:
Do any paths that are different between the current branch and
the branch we are switching to have local (i.e., either in the
index or in the working tree) change [Yes/No]?
- When the answer is "yes", save the local changes to a new stash
entry, and clear the local changes from the index and from the
working tree. If not, do not bother with stash at all.
- Switch to other branch the usual way. This will never conflict.
- If we created a stash entry earlier, try to unstash it. It may
conflict or it may not.
- If it does not conflict, then we are done. We drop that stash
entry, and tell nothing about the stash to the user, as there
is nothing they can do to the now-consumed stash.
- If it does conflict, tell the user that the original change is
in the stash, and can be used to recover if you botch the
conflict resolution, and also tell the user that they need to
drop the stash entry once they are done with the change that
caused this current conflict.
Essentially, the new "autostaash only when needed" would become a
much better reimplementation of the "-m" option. From the point of
view of a user who is used to "checkout -m", the basic workflow
would be the same, only with vast improvement.
- It may not conflict and merge cleanly, in which case they do not
have to do anything. This is the same as status quo.
- It may conflict and they find it too involved to resolve right at
the moment, in which case they now have a choiceto say "git reset
--hard", essentially declaring "I prioritize working on this new
branch; I'll deal with the work in progress I started on the
previous branch later", and then later they can "git stash pop"
to deal with it.
Which is a vast improvement over the current "-m" that gives you
only one chance to resolve it right.
- It may conflict and they may be able to resolve cleanly, in which
case they have to remember that they need to do an extra thing
(i.e., drop the stash we created just in case) but that may not
be too bad a tradeoff.
If we can sell it as an improved implementation of "-m", we probably
can lose some code that the current "-m" implementation uses to do
its merge; we'd be instead using the "unstash" code paths.
And the new helper function to detect if switching from one commit
to another commit would never conflict can later be used to enhance
"git rebase" as well---we could call it N times to rebase a branch
with N commits and if all steps are clear, we do not have to insist
that there is no local changes like we do currently.
Hmm?
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-12 14:40 ` Junio C Hamano
@ 2026-03-13 14:29 ` Phillip Wood
2026-03-14 17:17 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-03-13 14:29 UTC (permalink / raw)
To: Junio C Hamano, Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren
On 12/03/2026 14:40, Junio C Hamano wrote:
>
> Perhaps doing it this way would make it more worth doing?
>
> - At the beginning of branch switching, ask a new helper function
> that takes the branch we are switching to as an argument this
> question:
>
> Do any paths that are different between the current branch and
> the branch we are switching to have local (i.e., either in the
> index or in the working tree) change [Yes/No]?
>
> - When the answer is "yes", save the local changes to a new stash
> entry, and clear the local changes from the index and from the
> working tree. If not, do not bother with stash at all.
Can we avoid the extra check and stash if the user passed "--autostash"
and unpack_trees() fails because it would overwrite local changes in
merge_working_tree()?
> If we can sell it as an improved implementation of "-m", we probably
> can lose some code that the current "-m" implementation uses to do
> its merge; we'd be instead using the "unstash" code paths.
That would be nice but I think "git checkout --recurse-submodules -m
<branch>" currently updates submodules whereas "git stash" does not know
how to recurse submodules.
It would be nice to teach "git stash" to recurse submodules but I don't
think it is completly straight forward as we'd need to store the object
id of the submodule's stash commit in the parent stash.
Thanks
Phillip
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-13 14:29 ` Phillip Wood
@ 2026-03-14 17:17 ` Junio C Hamano
2026-03-16 16:36 ` Phillip Wood
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-14 17:17 UTC (permalink / raw)
To: Phillip Wood; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 12/03/2026 14:40, Junio C Hamano wrote:
>>
>> Perhaps doing it this way would make it more worth doing?
>>
>> - At the beginning of branch switching, ask a new helper function
>> that takes the branch we are switching to as an argument this
>> question:
>>
>> Do any paths that are different between the current branch and
>> the branch we are switching to have local (i.e., either in the
>> index or in the working tree) change [Yes/No]?
>>
>> - When the answer is "yes", save the local changes to a new stash
>> entry, and clear the local changes from the index and from the
>> working tree. If not, do not bother with stash at all.
>
> Can we avoid the extra check and stash if the user passed "--autostash"
> and unpack_trees() fails because it would overwrite local changes in
> merge_working_tree()?
Sorry, but I couldn't quite figure out what you are saying here.
My guess on one part of what it says is that an explicit
"--autostash", we should stash without second guessing the user
(i.e., avoid chedk and stash). But then the latter part of the
sentence "and unpack_trees() fails ..." do not quite parse.
If the user gave "--autostash" and we check with unpack_trees()
dry-run and find out that a normal branch switch will be interfered
by the local changes, then we would stash, but that check made by a
dry-run unpack_trees() is not an "extra" check, so, that does not
work as a guess of what you are saying, either.
>> If we can sell it as an improved implementation of "-m", we probably
>> can lose some code that the current "-m" implementation uses to do
>> its merge; we'd be instead using the "unstash" code paths.
>
> That would be nice but I think "git checkout --recurse-submodules -m
> <branch>" currently updates submodules whereas "git stash" does not know
> how to recurse submodules.
Hmph, I do not do submodules outside what we already have, and I
certainly do not do "checkout --recurse-submodules" with or without
"-m" with local changes in our submodule.
But does "git stash" even need to know about recursing into
submodules for this? When checkout recurses into a submodule, that
checkout that is working in the repository of the submodule can
handle "-m" itself, which may stash the local changes made in the
submodule, no?
> It would be nice to teach "git stash" to recurse submodules but I don't
> think it is completly straight forward as we'd need to store the object
> id of the submodule's stash commit in the parent stash.
No, let's not add more commands that take "--recurse-submodules", if
we do not have to.
Thanks.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-14 17:17 ` Junio C Hamano
@ 2026-03-16 16:36 ` Phillip Wood
2026-03-16 20:04 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Phillip Wood @ 2026-03-16 16:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
On 14/03/2026 17:17, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> On 12/03/2026 14:40, Junio C Hamano wrote:
>>>
>>> Perhaps doing it this way would make it more worth doing?
>>>
>>> - At the beginning of branch switching, ask a new helper function
>>> that takes the branch we are switching to as an argument this
>>> question:
>>>
>>> Do any paths that are different between the current branch and
>>> the branch we are switching to have local (i.e., either in the
>>> index or in the working tree) change [Yes/No]?
>>>
>>> - When the answer is "yes", save the local changes to a new stash
>>> entry, and clear the local changes from the index and from the
>>> working tree. If not, do not bother with stash at all.
>>
>> Can we avoid the extra check and stash if the user passed "--autostash"
>> and unpack_trees() fails because it would overwrite local changes in
>> merge_working_tree()?
>
> Sorry, but I couldn't quite figure out what you are saying here.
>
> My guess on one part of what it says is that an explicit
> "--autostash", we should stash without second guessing the user
> (i.e., avoid chedk and stash). But then the latter part of the
> sentence "and unpack_trees() fails ..." do not quite parse.
>
> If the user gave "--autostash" and we check with unpack_trees()
> dry-run and find out that a normal branch switch will be interfered
> by the local changes, then we would stash, but that check made by a
> dry-run unpack_trees() is not an "extra" check, so, that does not
> work as a guess of what you are saying, either.
Why is the dry-run of unpack_trees() not an extra check? I was assuming
that it was because we do the dry-run and then do it for real after
possibly stashing any local changes. That's why I was wondering if we
could avoid the dry-run by creating the stash if the non-dry-run
unpack_trees() failed. Looking at the unpack_trees() implementation it
can fail for a variety of reasons, only some (one?) of which can be
addressed by stashing local changes but there does not seem to be a way
for the caller to determine what caused it to fail.
>>> If we can sell it as an improved implementation of "-m", we probably
>>> can lose some code that the current "-m" implementation uses to do
>>> its merge; we'd be instead using the "unstash" code paths.
>>
>> That would be nice but I think "git checkout --recurse-submodules -m
>> <branch>" currently updates submodules whereas "git stash" does not know
>> how to recurse submodules.
>
> Hmph, I do not do submodules outside what we already have, and I
> certainly do not do "checkout --recurse-submodules" with or without
> "-m" with local changes in our submodule.
>
> But does "git stash" even need to know about recursing into
> submodules for this? When checkout recurses into a submodule, that
> checkout that is working in the repository of the submodule can
> handle "-m" itself, which may stash the local changes made in the
> submodule, no?
Oh, because this all happens in a single command then yes, I think we
can. When I wrote that I'd been thinking about a recent question about
rebase not recursing submodules on discord and what it would take to
make "git rebase --recurse-submodules --autostash" work. There we need
to be able to retrive the stash in a different process to the one that
created it so we need some way of tracking the stashed changes in each
submodule.
It turns out I'd misremembered what "git checkout -m
--recurse-submodules" does at the moment - after testing it, it seems to
simply nuke an uncommitted submodule changes rather than merging them.
Thanks
Phillip
>> It would be nice to teach "git stash" to recurse submodules but I don't
>> think it is completly straight forward as we'd need to store the object
>> id of the submodule's stash commit in the parent stash.
>
> No, let's not add more commands that take "--recurse-submodules", if
> we do not have to.
>
> Thanks.
>
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-16 16:36 ` Phillip Wood
@ 2026-03-16 20:04 ` Junio C Hamano
2026-03-17 9:47 ` Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-16 20:04 UTC (permalink / raw)
To: Phillip Wood; +Cc: Harald Nordgren via GitGitGadget, git, Harald Nordgren
Phillip Wood <phillip.wood123@gmail.com> writes:
> Why is the dry-run of unpack_trees() not an extra check? I was assuming
> that it was because we do the dry-run and then do it for real after
> possibly stashing any local changes. That's why I was wondering if we
> could avoid the dry-run by creating the stash if the non-dry-run
> unpack_trees() failed.
Ah, I didn't even think about that possibility.
Try to unpack anyway, and if unpack_trees() branch switching
succeeds, we are done. Otherwise, we can trust that unpack_trees()
did not do _anything_ to the index or the working tree files, so we
can create the stash at that time.
Makes sense.
> It turns out I'd misremembered what "git checkout -m
> --recurse-submodules" does at the moment - after testing it, it seems to
> simply nuke an uncommitted submodule changes rather than merging them.
Makes sense.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-16 20:04 ` Junio C Hamano
@ 2026-03-17 9:47 ` Harald Nordgren
2026-03-19 8:25 ` Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-03-17 9:47 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren, phillip.wood123
>> Why is the dry-run of unpack_trees() not an extra check? I was assuming
>> that it was because we do the dry-run and then do it for real after
>> possibly stashing any local changes. That's why I was wondering if we
>> could avoid the dry-run by creating the stash if the non-dry-run
>> unpack_trees() failed.
>
> Ah, I didn't even think about that possibility.
>
> Try to unpack anyway, and if unpack_trees() branch switching
> succeeds, we are done. Otherwise, we can trust that unpack_trees()
> did not do _anything_ to the index or the working tree files, so we
> can create the stash at that time.
>
> Makes sense.
Interesting idea, and thanks for your help with this! I gave it a shot with
this simplification.
It passes the tests, which either means it works, or just that the test
coverage is not good enough to detect new issues introduced by me here.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-17 9:47 ` Harald Nordgren
@ 2026-03-19 8:25 ` Harald Nordgren
2026-03-19 16:48 ` Junio C Hamano
0 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-03-19 8:25 UTC (permalink / raw)
To: haraldnordgren; +Cc: git, gitgitgadget, gitster, phillip.wood123
Hi Junio and Jeff!
Did you get a chance to look at the latest changes?
The scope of this grew a lot from my original idea of auto-stashing, so I'm
not 100% convinced that changing '-m' is necessary here. My fear is to
break something, especially since 'checkout -m' is a feature I never used
before touching it here, so I don't have a good sense of how it should
work.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-19 8:25 ` Harald Nordgren
@ 2026-03-19 16:48 ` Junio C Hamano
2026-03-31 12:16 ` Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-03-19 16:48 UTC (permalink / raw)
To: Harald Nordgren; +Cc: git, gitgitgadget, phillip.wood123
Harald Nordgren <haraldnordgren@gmail.com> writes:
> Hi Junio and Jeff!
>
> Did you get a chance to look at the latest changes?
>
> The scope of this grew a lot from my original idea of auto-stashing, so I'm
> not 100% convinced that changing '-m' is necessary here. My fear is to
> break something, especially since 'checkout -m' is a feature I never used
> before touching it here, so I don't have a good sense of how it should
> work.
FWIW, I very much like what I see in
$ git checkout hn/git-checkout-m-with-stash && git diff @{1}
output. It is great that we do not have to do any dry-run, because
the "real" run safely aborts, we can do the "stash && merge && unstash"
dance as a fallback instead. All the credit goes to Phillip and you
for the idea and the execution of this.
I do use "checkout -m" a few times a week, but I do not do anything
complex with submodules or run the command with unrelated local
modifications, so there may be changes in behaviour I haven't seen
in corner cases that I do not exercise.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-19 16:48 ` Junio C Hamano
@ 2026-03-31 12:16 ` Harald Nordgren
2026-04-09 11:50 ` Harald Nordgren
` (2 more replies)
0 siblings, 3 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-03-31 12:16 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren, phillip.wood123
> FWIW, I very much like what I see in
>
> $ git checkout hn/git-checkout-m-with-stash && git diff @{1}
>
> output. It is great that we do not have to do any dry-run, because
> the "real" run safely aborts, we can do the "stash && merge && unstash"
> dance as a fallback instead. All the credit goes to Phillip and you
> for the idea and the execution of this.
>
> I do use "checkout -m" a few times a week, but I do not do anything
> complex with submodules or run the command with unrelated local
> modifications, so there may be changes in behaviour I haven't seen
> in corner cases that I do not exercise.
I wonder if my implementation is not really up to par. I have ran into a
few "conflicts", were 'git stash pop' simply worked afterwards.
So not quite production ready.
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-31 12:16 ` Harald Nordgren
@ 2026-04-09 11:50 ` Harald Nordgren
2026-04-09 12:06 ` Harald Nordgren
2026-04-09 12:12 ` Harald Nordgren
2 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-09 11:50 UTC (permalink / raw)
To: haraldnordgren; +Cc: git, gitgitgadget, gitster, phillip.wood123
>> FWIW, I very much like what I see in
>>
>> $ git checkout hn/git-checkout-m-with-stash && git diff @{1}
>>
>> output. It is great that we do not have to do any dry-run, because
>> the "real" run safely aborts, we can do the "stash && merge && unstash"
>> dance as a fallback instead. All the credit goes to Phillip and you
>> for the idea and the execution of this.
>>
>> I do use "checkout -m" a few times a week, but I do not do anything
>> complex with submodules or run the command with unrelated local
>> modifications, so there may be changes in behaviour I haven't seen
>> in corner cases that I do not exercise.
>
> I wonder if my implementation is not really up to par. I have ran into a
> few "conflicts", were 'git stash pop' simply worked afterwards.
>
> So not quite production ready.
Update on this: I realized that the issues I ran into was happening
because of a sub-shell, so it's resolved by running like this:
export GIT_EXEC_PATH=/Users/Harald/git-repos/github.com/git/git && \
/Users/Harald/git-repos/github.com/git/git/git checkout -m -
So thus, it's not a real problem.
I think this is ready to be reviewed, does anyone have time to take a look?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-31 12:16 ` Harald Nordgren
2026-04-09 11:50 ` Harald Nordgren
@ 2026-04-09 12:06 ` Harald Nordgren
2026-04-09 18:35 ` Junio C Hamano
2026-04-09 12:12 ` Harald Nordgren
2 siblings, 1 reply; 69+ messages in thread
From: Harald Nordgren @ 2026-04-09 12:06 UTC (permalink / raw)
To: haraldnordgren; +Cc: git, gitgitgadget, gitster, phillip.wood123
>> FWIW, I very much like what I see in
>>
>> $ git checkout hn/git-checkout-m-with-stash && git diff @{1}
>>
>> output. It is great that we do not have to do any dry-run, because
>> the "real" run safely aborts, we can do the "stash && merge && unstash"
>> dance as a fallback instead. All the credit goes to Phillip and you
>> for the idea and the execution of this.
>>
>> I do use "checkout -m" a few times a week, but I do not do anything
>> complex with submodules or run the command with unrelated local
>> modifications, so there may be changes in behaviour I haven't seen
>> in corner cases that I do not exercise.
>
> I wonder if my implementation is not really up to par. I have ran into a
> few "conflicts", were 'git stash pop' simply worked afterwards.
>
> So not quite production ready.
Update on this: I realized that the issues I ran into was happening
because of a sub-shell, so it's resolved by running like this:
export GIT_EXEC_PATH=/Users/Harald/git-repos/github.com/git/git && \
/Users/Harald/git-repos/github.com/git/git/git checkout -m -
So thus, it's not a real problem.
I think this is ready to be reviewed, does anyone have time to take a look?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-09 12:06 ` Harald Nordgren
@ 2026-04-09 18:35 ` Junio C Hamano
2026-04-09 21:29 ` Harald Nordgren
0 siblings, 1 reply; 69+ messages in thread
From: Junio C Hamano @ 2026-04-09 18:35 UTC (permalink / raw)
To: Harald Nordgren; +Cc: git, gitgitgadget, phillip.wood123
Harald Nordgren <haraldnordgren@gmail.com> writes:
> Update on this: I realized that the issues I ran into was happening
> because of a sub-shell, so it's resolved by running like this:
>
> export GIT_EXEC_PATH=/Users/Harald/git-repos/github.com/git/git && \
> /Users/Harald/git-repos/github.com/git/git/git checkout -m -
>
> So thus, it's not a real problem.
In other words, you were not consistently trying the version of Git
you just built?
Thanks for a good news.
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-04-09 18:35 ` Junio C Hamano
@ 2026-04-09 21:29 ` Harald Nordgren
0 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-09 21:29 UTC (permalink / raw)
To: gitster; +Cc: git, gitgitgadget, haraldnordgren, phillip.wood123
> In other words, you were not consistently trying the version of Git
you just built?
I was, but the difference here is the this logic calls another instance of
Git halfway through, and I didn't realize until today that that other
instance ended up being the system Git instead. So technically, I was only
half-using it -- but accident.
Maybe I should consider installing it globally on my machine, via PATH or
otherwise!
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [PATCH] checkout: add --autostash option for branch switching
2026-03-31 12:16 ` Harald Nordgren
2026-04-09 11:50 ` Harald Nordgren
2026-04-09 12:06 ` Harald Nordgren
@ 2026-04-09 12:12 ` Harald Nordgren
2 siblings, 0 replies; 69+ messages in thread
From: Harald Nordgren @ 2026-04-09 12:12 UTC (permalink / raw)
To: haraldnordgren; +Cc: git, gitgitgadget, gitster, phillip.wood123
>> FWIW, I very much like what I see in
>>
>> $ git checkout hn/git-checkout-m-with-stash && git diff @{1}
>>
>> output. It is great that we do not have to do any dry-run, because
>> the "real" run safely aborts, we can do the "stash && merge && unstash"
>> dance as a fallback instead. All the credit goes to Phillip and you
>> for the idea and the execution of this.
>>
>> I do use "checkout -m" a few times a week, but I do not do anything
>> complex with submodules or run the command with unrelated local
>> modifications, so there may be changes in behaviour I haven't seen
>> in corner cases that I do not exercise.
>
> I wonder if my implementation is not really up to par. I have ran into a
> few "conflicts", were 'git stash pop' simply worked afterwards.
>
> So not quite production ready.
Update on this: I realized that the issues I ran into was happening
because of a sub-shell, so it's resolved by running like this:
export GIT_EXEC_PATH=/Users/Harald/git-repos/github.com/git/git && \
/Users/Harald/git-repos/github.com/git/git/git checkout -m -
So thus, it's not a real problem.
I think this is ready to be reviewed, does anyone have time to take a look?
Harald
^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2026-05-10 1:01 UTC | newest]
Thread overview: 69+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-14 9:12 [PATCH] remote: use plural-only message for diverged branch status Harald Nordgren via GitGitGadget
2026-03-14 9:16 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-03-14 16:52 ` [PATCH] remote: use plural-only message for diverged branch status Junio C Hamano
2026-03-14 18:38 ` Junio C Hamano
2026-03-14 20:08 ` Phillip Wood
2026-03-15 2:08 ` Junio C Hamano
2026-03-16 10:49 ` Phillip Wood
2026-03-16 17:06 ` Junio C Hamano
2026-03-25 4:29 ` Kaartic Sivaraam
-- strict thread matches above, loose matches on Subject: below --
2026-05-03 22:39 [PATCH] fetch: add fetch.pruneLocalBranches config Junio C Hamano
2026-05-04 18:28 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-05-10 1:01 ` Junio C Hamano
2026-05-03 20:59 [PATCH v5] checkout: extend --track with a "fetch" mode to refresh start-point Junio C Hamano
2026-05-03 22:32 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-29 10:02 [PATCH v16 0/5] checkout: 'autostash' " Phillip Wood
2026-04-29 11:11 ` [PATCH] checkout: add --autostash option " Harald Nordgren
2026-04-28 9:35 [PATCH v15 5/5] checkout -m: autostash when switching branches Phillip Wood
2026-04-28 18:08 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-28 9:33 [PATCH v15 3/5] sequencer: teach autostash apply to take optional conflict marker labels Phillip Wood
2026-04-28 15:21 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-28 9:32 [PATCH v15 1/5] stash: add --label-ours, --label-theirs, --label-base for apply Phillip Wood
2026-04-28 15:16 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-15 16:24 [PATCH v14 0/5] checkout: 'autostash' " Harald Nordgren via GitGitGadget
2026-04-21 7:53 ` [PATCH] checkout: add --autostash option " Harald Nordgren
2026-04-21 9:34 ` Phillip Wood
2026-04-22 17:58 ` Harald Nordgren
2026-04-14 15:56 [PATCH v12 0/4] checkout: 'autostash' " Junio C Hamano
2026-04-14 20:16 ` [PATCH] checkout: add --autostash option " Harald Nordgren
2026-04-14 20:56 ` Junio C Hamano
2026-04-16 10:05 ` Harald Nordgren
2026-04-16 14:45 ` Junio C Hamano
2026-04-16 17:53 ` Harald Nordgren
2026-04-14 14:07 [PATCH v12 4/4] checkout: -m (--merge) uses autostash when switching branches Phillip Wood
2026-04-14 20:06 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-15 9:35 ` Phillip Wood
2026-04-14 20:13 ` Harald Nordgren
2026-04-15 8:19 ` Harald Nordgren
2026-04-15 9:34 ` Phillip Wood
2026-04-15 8:16 ` Harald Nordgren
2026-04-15 9:36 ` Phillip Wood
2026-04-14 14:06 [PATCH v12 3/4] sequencer: teach autostash apply to take optional conflict marker labels Phillip Wood
2026-04-14 18:44 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-14 14:06 [PATCH v12 2/4] sequencer: allow create_autostash to run silently Phillip Wood
2026-04-14 18:35 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-14 14:05 [PATCH v12 1/4] stash: add --label-ours, --label-theirs, --label-base for apply Phillip Wood
2026-04-14 18:56 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-14 20:08 ` Harald Nordgren
2026-04-15 9:34 ` Phillip Wood
2026-04-15 15:34 ` Harald Nordgren
2026-04-13 22:45 [PATCH v10 0/4] checkout: 'autostash' " Junio C Hamano
2026-04-14 7:29 ` [PATCH] checkout: add --autostash option " Harald Nordgren
2026-04-14 13:29 ` Junio C Hamano
2026-04-14 14:14 ` Junio C Hamano
2026-04-14 17:42 ` Junio C Hamano
2026-04-11 18:38 [PATCH v9 4/4] checkout: -m (--merge) uses autostash when switching branches Jeff King
2026-04-11 18:51 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-11 19:11 ` Jeff King
2026-04-10 16:34 [PATCH v8 3/4] sequencer: teach autostash apply to take optional conflict marker labels Junio C Hamano
2026-04-10 18:48 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-10 15:39 [PATCH v8 2/4] sequencer: allow create_autostash to run silently Phillip Wood
2026-04-10 18:53 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-10 15:39 [PATCH v8 1/4] stash: add --ours-label, --theirs-label, --base-label for apply Phillip Wood
2026-04-10 19:18 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-09 23:49 [PATCH v8 4/4] checkout: -m (--merge) uses autostash when switching branches Chris Torek
2026-04-10 14:38 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-09 17:55 [PATCH v7 4/4] checkout: -m (--merge) uses autostash when switching branches Junio C Hamano
2026-04-09 20:32 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-09 17:32 [PATCH v7 3/4] sequencer: teach autostash apply to take optional conflict marker labels Junio C Hamano
2026-04-09 21:20 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-09 17:25 [PATCH v7 1/4] stash: add --ours-label, --theirs-label, --base-label for apply Junio C Hamano
2026-04-09 20:31 ` [PATCH] checkout: add --autostash option for branch switching Harald Nordgren
2026-04-09 17:00 [PATCH v7 0/4] checkout: 'autostash' " Junio C Hamano
2026-04-09 21:23 ` [PATCH] checkout: add --autostash option " Harald Nordgren
2026-03-13 17:16 [PATCH v3] " Junio C Hamano
2026-03-13 19:33 ` [PATCH] " Harald Nordgren
2026-03-13 20:30 ` Junio C Hamano
2026-03-12 19:50 [PATCH v2] " Junio C Hamano
2026-03-13 9:22 ` [PATCH] " Harald Nordgren
2026-03-12 13:26 Harald Nordgren via GitGitGadget
2026-03-12 14:40 ` Junio C Hamano
2026-03-13 14:29 ` Phillip Wood
2026-03-14 17:17 ` Junio C Hamano
2026-03-16 16:36 ` Phillip Wood
2026-03-16 20:04 ` Junio C Hamano
2026-03-17 9:47 ` Harald Nordgren
2026-03-19 8:25 ` Harald Nordgren
2026-03-19 16:48 ` Junio C Hamano
2026-03-31 12:16 ` Harald Nordgren
2026-04-09 11:50 ` Harald Nordgren
2026-04-09 12:06 ` Harald Nordgren
2026-04-09 18:35 ` Junio C Hamano
2026-04-09 21:29 ` Harald Nordgren
2026-04-09 12:12 ` Harald Nordgren
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.