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

[Phillip Wood <phillip.wood123@gmail.com>]

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