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

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Oct 17, 2009, 19:41 UTC
Message-ID: <20091017194153.GA30003@atjola.homenet>
In-Reply-To: <7vaazqcry5.fsf@alter.siamese.dyndns.org>

On 2009.10.17 02:04:02 -0700, Junio C Hamano wrote:

Show 8 quoted lines

> 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.

Hm, which cases would that be? I basically see three cases:

 1) No uncommitted changes => No problem
 2) Uncommitted changes merge cleanly => No problem
 3) Uncommitted changes causes conflicts =>
   - User can resolve
   - User can start over (git update --retry)
   - User can give up (git update --abort)

Of course the user can clearly see that some state was saved (otherwise you couldn't retry or abort), but I don't see how the user is "forced" in any way, he just gets those two commands to work with (which internally just wrap reset + stash apply, making things more convenient).

I do see problems with a "stash around merge" thing ("stash" around rebase seems easier, as that could just create a commit and reset later, but I'm not exactly sure that such smartness is a good idea). As soon as the merge has conflicts, you need to know that you have to unstash after committing the merge, but what I have in mind is fast-forward only (or possibly reset, when upstream was rewritten). Primarily for users that don't commit at all, but just look at things [*1*]. And also for the semi-detached HEAD case, in which you may not commit and in which doing a merge/rebase is therefore not an option, but git still knows what to fetch/checkout by using the discussed extra info in HEAD, or by examining the reflog.

Show 6 quoted lines

> > 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.

The state they were in before they did the "git stash" part.

*work on stuff not ready to be committed* git pull # refused git stash git pull git stash apply # Conflicts, user decides that he wants go back

At that point, you need the reflog (also handle fast-forwards), and do:

git reset --hard HEAD@{1} git stash apply --index

Of course, a more correct way might be to use commit and rebase instead:

*work on stuff not ready to be committed* git pull # refused git add -A # Or whatever git commit git pull --rebase # conflicts, decide to abort git rebase --abort git reset HEAD^

But that still needs the extra "reset HEAD^" step to really get back to the state with your uncommitted changes.

The problem with "svn up" is that there's no other way, and no way back. Git has other ways, but no convenient one for non-committers and no "obvious" way to go back, should you decide that you actually prefer not to update after seeing the conflicts.

Anyway, this isn't _my_ itch and to some (large) degree I'm trying to guess what someone else would expect. If at all, I'm more interested in a command that figures out which remote tracking branch I checked out, and that updates it, and updates my work tree/index as well. Uncommitted changes aren't important to me there. So I'll simply give up on that part.

Björn

[*1*] One could also say: Users that don't give a damn about git, but just need it to get the code and maybe have some minor, uncommitted modifications on top. I'm _not_ thinking about users that actually commit and do stuff. Those should use merge/rebase/pull, and get a complaint from "git update" if the update is not a fast-forward one, telling them what to use instead.