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, 08:40 UTC
Message-ID: <20091017084025.GC5474@atjola.homenet>
In-Reply-To: <7vws2ue8yc.fsf@alter.siamese.dyndns.org>

On 2009.10.17 01:11:23 -0700, Junio C Hamano wrote:

Show 18 quoted lines

> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> 
> > ... If so, it does a "git checkout --merge
> > <upstream>" (possibly leaving conflicts for the uncommitted changes,
> > just like "svn update").
> 
> Up to this point I was reading with quite a lot of interest.  But here I
> strongly disagree to the point of getting actually disgusted.
> 
> "svn up" is one of the areas Subversion folks failed to make their system
> a better CVS.  It has the same "local changes are lost in the merge
> conflict mess in an irreversible way" failure mode, and we shouldn't be
> making it easy to new people.  It is not something we should emulate.
> 
> You can and should instead refuse the update, and suggest committing first
> so that the user has a safe record of what he has done and the merge with
> upstream can be retried if necessary.  As you need to have that "refuse
> but guide the lost soul by telling what to do" mode anyway when...

Hm, probably I (mentally) focussed to much on "people that just want to look" and didn't really think that they'd have much to lose. Not sure. Over the time, I got so used to do "git checkout --merge <something>" with some I-don't-care-much debugging or whatever change, that I lost track of how bad that was with svn. If I have just I care about, I commit, and then "git update" would no longer be an option anyway. But yeah, not a good option to give to the uninitiated user...

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? But I fail to come up with a convenient and at the same time error safe way for such a "stash wrap". The only thing that comes to mind would be to have "git update" completely wrapping the thing:

git update
 - Stashes uncommitted changes
 - fetches
 - checks out
 - "stash apply --index", if that fails, just "stash apply"

If there are conflicts, show options (similar to what rebase does):

git update --retry # Start over
 - reset --hard
 - "stash apply --index", if that fails, just "stash apply"

git update --abort
 - git reset --hard HEAD@{1}
 - "stash apply --index"
 - "stash drop stash@{0}"

git update --done
 - Check whether there are still unmerged files, if so: complain
 - otherwise: "stash drop stash@{0}"

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.

Björn