Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was

[Junio C Hamano <gitster@pobox.com>]

Björn Steinbrink <B.Steinbrink@gmx.de> 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.