From: Junio C Hamano Date: Sat, 14 Mar 2026 17:17:59 GMT Subject: Re: [PATCH] checkout: add --autostash option for branch switching Message-ID: In-Reply-To: <953b5842-a4ae-40f6-8cae-c4f81239c903@gmail.com> Phillip Wood 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 > " 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.