Matthieu Moy <> writes:

> Ramkumar Ramachandra <> writes:
>> Matthieu Moy wrote:
>>> AFAICT, "git merge --abort" is an alias for "git reset --merge"
>> Yes, that is correct.
>>> which
>>> was precisely designed to reset only modifications comming from a merge,
>>> and not the local changes that were present before the merge was
>>> started. The man pages are relatively obscure on the subject, but I'd
>>> call that a documentation bug.
>> I see.  Either way, we need a clean worktree for it to work, no?
> No, you don't. Just try if you're not convinced:

Heh, I still remember breaking "git merge" and got yelled at loudly.


>>> It does. stashing means the user will have to "stash pop" later. One
>>> extra step, one extra opportunity to forget something important.
>> That's only if there are conflicts.  If there are conflicts, you'll
>> have to stash anyway if:
>> - You're doing a pull-merge and want merge --abort to work.
> Again, no.
>>> A minor annoyance is that it will touch files that have no reason to be
>>> touched, hence may trigger extra rebuilds with "make", disturbing text
>>> editors that have the file open, etc.
>> Okay, I need to ask you something at this point: do you ever run merge
>> on a dirty worktree unless you're absolutely sure that your local
>> changes won't conflict with the changes introduced by the merge? 
> Most of the time, I just run "git pull" or "git merge". I know it's
> conservative enough, to it will stop if there's anything dangerous.


> No, I'm not proposing to do anything for merge. There's no reason to try
> being uniform in conflict resolution for pull-merge and pull-rebase as
> it is already different now. We already have "git rebase --continue", we
> don't have "git merge --continue". So what? The fact that merge doesn't
> have the equivalent doesn't mean we should not do something for "rebase
> --continue".

Well said.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to