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?

> 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.
- You're doing a pull-rebase.

In the case when there are no conflicts, what is the problem?

> 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?  I
_never_ run merge on a dirty worktree myself.

> The fact that "git pull" just works on dirty trees with non-overlapping
> changes is an important feature of Git.

That's only a pull-merge.  Unfortunately, making uniform
means that we have to fall back to the least-common-denominator of
functionality (which is currently pull-rebase).

> I think you're taking it the wrong way. You seem to insist that
> autostash should be a pull feature. I think it should be a feature of
> merge and rebase, and the convenience script "git pull" should expose
> them to the user.
> I see no reason to prevent users running fetch and then merge or rebase
> to use the autostash feature.

Okay, so you're proposing a uniform --autostash feature for both merge
and rebase.  Sorry, I didn't get it last time due to the typos in your
email; yeah, this is worth investigating.

> As a user, when I run "git rebase --continue" and it tells me it's done,
> I expect the work to actually be done. This is the case today. This
> won't be the case after autostash is introduced if the user has to
> remember to run "stash pop" afterwards.

And how will you implement that for merge, since there is no merge
--continue to execute stash pop from?  Do you propose to make commit
do the stash pop'ing?
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