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

[Junio C Hamano <gitster@pobox.com>]

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.