Björn Steinbrink [off-list ref] 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...
... If a fast-forward is not possible, it
complains, telling the user that he needs to use "git merge/rebase/pull"
instead, and might want to create a branch head, in case of a detached
HEAD.
On 2009.10.17 01:11:23 -0700, Junio C Hamano wrote:
Björn Steinbrink [off-list ref] writes:
quoted
... 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