Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash

Matthieu Moy [off-list ref] writes:

Ramkumar Ramachandra [off-list ref] writes:

quoted

Matthieu Moy wrote:

quoted

AFAICT, "git merge --abort" is an alias for "git reset --merge"

Yes, that is correct.

quoted

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.

cf. http://thread.gmane.org/gmane.comp.version-control.git/9073

quoted

quoted

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.

quoted

quoted

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.

Exactly.

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.