Björn Steinbrink <B.Steinbrink@xxxxxx> writes: > Interestingly, I irregularly give advice to use "git stash; git > checkout; git stash apply" instead of "git checkout -m" on #git, as that > allows you to try again if you messed up the conflict resolution, and > even allows you to completely go back to the initial state. Maybe that > would be an option? As I already said many times (here and elsewhere), "up" is an inferior and more dangerous model we would be better off not following if we can. It is not even entirely CVS/SVN's fault that their "scm up" is an error prone operation. They use a centralized model, in which there is _no_ way to record your local modification and run a retryable merge, so they have an excuse to force users to do things in "work, then update without recording wip anywhere" order. You can afford to (and it is even more natural to) do things in "work, save and then merge" order with git. I simply cannot believe people who advocate for helping uninitiated would even think of modelling any "user friendliness" features around "up" model. The "save" part of the work-save-then-merge sequence should be made very visible to help people get used to the "not up, but work-save-then-merge" mental model. I do not think it would help people in the long run to make the "save" step less visible by wrapping the sequence into an unreliable "up" script, especially because the script would sometimes work but other times *has to* force users to know that what is happening behind the scene is work-save-then-merge in order to resolve and recover from conflicts anyway. > OTOH, it might be easier to just tell the user to do the stash thing > himself. But I wonder how many users would really know how to get back > to the initial state then. I agree with the first sentence, but I do not understand what "the initial state" you talk about here in the second sentence, sorry. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html