On 2009.10.17 02:04:02 -0700, Junio C Hamano wrote:
> 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.
> > 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.
--
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