Tao Klerks <tao@xxxxxxxxxx> writes: > At first I hoped that "git switch" might have fixed this - and in a > limited sense it has, in that instead of *silently discarding* the > merge state/metadata, it refuses with "fatal: cannot switch branch > while merging". I think this is in generally seen as a vast improvement over the "silently discarding" to have the safety valve. > I'd like to understand whether this behavior, the fact that you can't > easily/straightforwardly/intuitively complete a merge onto a new > branch (with the exact same "first parent" commit of course), is > intentional for some reason that I am failing to grasp, or just a > missing feature. > > It makes complete sense, of course, that switching to a *different > commit* than the one you were on when you started the merge, should be > illegal... but why would switching to the *same* commit be either > illegal (git switch behavior) or destructive (git checkout behavior), > as opposed to just letting you get on with it, as it does with other > in-progress local working tree states? I think this is mostly that nobody spent enough brain cycles to ponder on things like: - Is it always safe to switch from a merge in progress to a newly created branch that point at the same commit as HEAD? Why? Is the story the same if the switched-to branch is an existing one that happens to point at the same commit as HEAD? - Maybe the answer to the above question is not "it is not quite safe to switch during a conflicted merge, but by adjusting X and Y while switching to a new branch, we could make it safe". - Even if the answer to the question above is "yes it is always safe", if it is not safe for a similar situation that ends up in unmerged index (i.e. the index with any path at non-0 stage), the way we determine if we are in "a merge in progress" situation must be reliable. Is it? - Conversely, perhaps it is also safe to switch to a different branch that points at the same commit as HEAD from the conflicted state after some (but not necessarily all) of the following operations: "am -3", "cherry-pick" (single commit), "revert" (single commit), etc. Can we come up with a reliable way to determine if we are in such a situation? - These "other mergy operations" that can leave unmerged index may share the same "is not safe out of the box, but can be made safe by adjusting some stuff". After that is done, we could update the codepath in "git switch" that says "ah, your index is unmerged, so I will not let you switch" to instead say "your index is unmerged; let's first see if you are switching to the same commit as HEAD and then the way your index is unmerged was caused by an operation that we decided is safe to switch out of. It seems to be one of the situations that could be made safe, so let's do adjustment X and Y and let you switch". And the reason why "git switch" punts is because nobody bothered to, not because there fundamentally is some reason why it shouldn't work.
