On Thu, Mar 11, 2021 at 12:45 PM Tassilo Horn <tsdh@xxxxxxx> wrote: > >> Or that popping the stash again would also restore the MERGING state. > > > > This would make more sense: the stash records that part of the state, > > and then we make it available again later when the stash is applied. > > However, that feature doesn't exist yet. > > Too bad. Consider also what happens when `git stash apply` results in a merge conflict because of differences between your current index and the one you had when you originally saved the stash. This results in the usual merge conflict markers that then need to be cleaned up. Could we sanely deal with this in a world where we also tried to restore .git/MERGE_HEAD when the stash was applied. Something like `git stash apply --continue`, possibly after resolving the stash conflicts? But what if we stashed the merge conflict that resulted from the stash apply? I guess it would still work, but the stash history would be, um, interesting. I wonder if a fix could be as simple as recording the MERGE_HEAD as the third parent commit of the stash ref. I think that would provide all the information needed to put things back, except possibly for things like the rerere state, which is also set up during a conflict, and other incidentals like .git/MERGE_MSG. (And it feels like it might break compatibility with older versions that don't expect a third parent.) I would be a bit concerned about the possibility of silently creating an "evil merge". Suppose you stash this conflict on some branch and then pop it onto a different one. I expect we would then be prepared to store all those changes from a different branch including existing resolved merge conflicts into the new one. That could be surprising and subtle. But maybe I'm overthinking it. Wouldn't the stash apply result in merge conflicts that would catch out all the troubling parts? I think being able to stash during a merge conflict could be very useful. I do sometimes need to get back to a working state momentarily and a merge conflict represents a long pole to doing so. Similarly, it could be useful to stash a conflicted `git rebase` so I could return to it later and pick up where I left off. Now we really would need to store some extra metadata, though, like the todo-list and ORIG_HEAD. And we would definitely need some extra command line switch to tell stash (or rebase) that I want to include all the rebase state and also "pause" the rebase by restoring to my starting point. Thanks for raising the issue, Tassilo. This has obviously given me more ideas for things I forgot were missing. > > I can't offhand think of a reason it couldn't be implemented. It's > > possible that it would mess with somebody else's workflow (e.g., they > > think it's useful to stash some changes independent of the merging > > state, and then apply it later, perhaps while replaying the same or a > > similar merge). So it might need to be tied to a command-line option > > or similar. > > Everything breakes someones workflow [1], so an option would be fine. > > However, I'd suggest to protect users shooting in their foot with a > warning and confirmation query for the time being. I consider myself a > quite experienced git user but this stash trouble today came totally > unexpected. And I've asked on #git@xxxxxxxxxxxxxxxx and got no answer > which is totally uncommon. So I guess that this stash during merge > thing is pretty much a gray area. I don't think we could easily add the warning when the stash is applied since we have forgotten the merge existed in the first place. So we would have to do it during stash save. "Warning: You are stashing during a merge conflict and your merge state will not be restored by stash apply." Seems reasonable. Phil
