checkout: 'autostash' for branch switching#2234
Open
HaraldNordgren wants to merge 1 commit intogit:masterfrom
Open
checkout: 'autostash' for branch switching#2234HaraldNordgren wants to merge 1 commit intogit:masterfrom
HaraldNordgren wants to merge 1 commit intogit:masterfrom
Conversation
c1fc1bd to
5e4e84c
Compare
f3083fa to
12194f6
Compare
Contributor
Author
|
/submit |
|
Submitted as pull.2234.git.git.1773321998854.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
dscho
added a commit
to gitgitgadget/gitgitgadget
that referenced
this pull request
Mar 12, 2026
Avoid the extra space in this output: ``` Handling command /submit with argument at git/git#2234 (comment) ``` as in here when just running `/submit`: https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/actions/runs/23004209654/job/66796393071
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "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 yo
8000
u
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? |
12194f6 to
be2b697
Compare
Contributor
Author
|
/submit |
|
Submitted as pull.2234.v2.git.git.1773344022931.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Harald Nordgren wrote on the Git mailing list (how to reply to this email): Good point! I have been running this today, and it gets a bit annoying when
it's stashing and unstashing needlessly.
I updated the code!
Harald |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "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. |
e05c054 to
05f1e53
Compare
Contributor
Author
|
/submit |
|
Submitted as pull.2234.v3.git.git.1773393818235.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Harald Nordgren wrote on the Git mailing list (how to reply to this email): > 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 |
|
Phillip Wood wrote on the Git mailing list (how to reply to this email): 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 |
|
User |
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): "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.
|
05f1e53 to
bbabef6
Compare
|
Harald Nordgren wrote on the Git mailing list (how to reply to this email): > 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 |
bbabef6 to
3eede33
Compare
|
Junio C Hamano wrote on the Git mailing list (how to reply to this email): 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. |
|
This patch series was integrated into seen via e5f6635. |
147444a to
3ca9bd7
Compare
When switching branches with "git checkout -m", local modifications can block the switch. Teach the -m flow to create a temporary stash before switching and reapply it after. On success, only "Applied autostash." is shown. 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>
3ca9bd7 to
5d49c00
Compare
Contributor
Author
|
/submit |
|
Submitted as pull.2234.v4.git.git.1773482375668.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cc: Phillip Wood phillip.wood123@gmail.com