[PATCH] checkout: add --autostash option for branch switching

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren via GitGitGadget]

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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

"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?

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Phillip Wood]

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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

[PATCH] remote: use plural-only message for diverged branch status

[Harald Nordgren via GitGitGadget]

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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

>> 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

Re: [PATCH] remote: use plural-only message for diverged branch status

[Junio C Hamano]

"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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] remote: use plural-only message for diverged branch status

[Junio C Hamano]

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.

Re: [PATCH] remote: use plural-only message for diverged branch status

[Phillip Wood]

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

Re: [PATCH] remote: use plural-only message for diverged branch status

[Junio C Hamano]

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.

Re: [PATCH] remote: use plural-only message for diverged branch status

[Phillip Wood]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Phillip Wood]

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.
> 

Re: [PATCH] remote: use plural-only message for diverged branch status

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

>> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] remote: use plural-only message for diverged branch status

[Kaartic Sivaraam]

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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

>> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

>> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

>> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> Should we or should we not see an extra stack entry saved at this point?
> Don't we want to test it?

All of these should be fixed as well. Thanks!


Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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?

Fixed!


Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> I might suggest that this should recommend "git stash pop --index"
> (either always, or if the stashed index differs from the stash's parent).

Interesting! This is a new option that I've never seen before.



Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> Sorry, I just noticed that these three should have been updated when
> the actual parameters were renamed.

Good point!

I also switched it to prefix naming label_*, which makes more sense to me.


Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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.

No good reason, and I will revert it.

> This could be a "bool" and the users could pass "true" and "false". 

Agreed.


Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Jeff King]

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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> > 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> > 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> > +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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> > +                     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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

>    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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> > +	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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> > > +                     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

Re: [PATCH] checkout: add --autostash option for branch switching

[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

Re: [PATCH] checkout: add --autostash option for branch switching

[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

Re: [PATCH] checkout: add --autostash option for branch switching

[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

Re: [PATCH] checkout: add --autostash option for branch switching

[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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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.

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

Hi Phillip, did you have a chance to look at the latest changes?


Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Phillip Wood]

On 21/04/2026 08:53, Harald Nordgren wrote:
> Hi Phillip, did you have a chance to look at the latest changes?

Not yet, I should get round to it later this week. Junio is offline for 
at least the next week, I'll make sure I've reviewed them by the time he 
returns.

Thanks

Phillip

> 
> Harald

Re: [PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

👍


Harald

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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.

I suspect that it is a lot of work, so maybe also better to do later.


Harald

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Thank you too!


Harald

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> How about rewriting everything up to and including this "Tie the new
> ..." line perhaps like so:

Done!


Harald

[PATCH] checkout: add --autostash option for branch switching

[Harald Nordgren]

> 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

Re: [PATCH] checkout: add --autostash option for branch switching

[Junio C Hamano]

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".