Björn Steinbrink <B.Steinbrink@xxxxxx> writes:
> 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)
By "--abort", if you meant to discard the local change, that is only
suitable for people who would say "what I was doing was minor anyway, and
I'll redo them based on the updated upstream", and may not be so useful, I
think. The user may want to pretend that he did not even start "update"
(i.e. not pulled while he was still working on something) at this point,
and if you meant by "give up" (aka --abort) to "reset --hard @{1} &&
unstash", I think it makes quite a lot of sense. Then the user has an
option to fork a topic at that point:
git update --abort
git checkout -b topic
work on more with committing
git checkout master
git update
But then this starts to look more like an enhanced failure recovery mode
for "git pull" command.
In addition, I think that you would internally implement the "save" step
with "stash" (which would be a sane thing to do), but then you would need
to worry about the case where the user was in the middle of a merge (or
"revert", "cherry-pick", "checkout -m") that did not complete. "git pull"
fails upfront, says why and tells users what to do. "git update" should
do the same.
> 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*].
Ok. If you have a clean way to guarantee that "update" users won't
commit, I think the above would sort of make sense and my earlier worries
about (1) a user who wish he did not fetch and (2) a user who was doing
something more complex and had conflicts already would go away.
If the sole target audience is "minor changes only, never committing"
people, then I would even rescind my earlier suggestion on --abort; it
should mean "remove the minor changes and get pristine copy of the
upstream---the user will redo the minor changes to adjust to the updated
upstream from scratch", to keep the end user experience simpler and
clearer.
I am undecided if it is a good thing to divide the userbase into two
classes, "update" people and "work-commit-fetch-merge-resolve" people.
> [*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