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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 14, 2026, 17:17 UTC
Message-ID: <xmqqms0awcs8.fsf@gitster.g>
In-Reply-To: <953b5842-a4ae-40f6-8cae-c4f81239c903@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 19 quoted lines

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

Show 7 quoted lines

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