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

Ramkumar Ramachandra [off-list ref] writes:

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:

$ git checkout -b branch
Switched to a new branch 'branch'
$ date > test.txt && git commit -m 'on branch' test.txt
[branch 2482623] on branch
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout -
Switched to branch 'master'
$ date > test.txt && git commit -m 'on master' test.txt
[master c322d35] on master
 1 file changed, 1 insertion(+), 1 deletion(-)
$ date > other.txt 
$ git status
# On branch master
# Changes not staged for commit:
#
#       modified:   other.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git merge branch
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.
$ git status
# On branch master
# You have unmerged paths.
#
# Unmerged paths:
#
#       both modified:      test.txt
#
# Changes not staged for commit:
#
#       modified:   other.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git merge --abort
$ git status
# On branch master
# Changes not staged for commit:
#
#       modified:   other.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ 

There may be corner-cases where it doesn't work, but I never encountered
such case.

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

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.

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

You may want to, but you don't have to. pull-merge and pull-rebase
already have different behavior in case of non-overlapping changes:

$ git pull --rebase . branch
Cannot pull with rebase: You have unstaged changes.
Please commit or stash them.
$ git pull --no-rebase . branch
From .
 * branch            branch     -> FETCH_HEAD
[...]

I don't see any reason to restrict to the common denominator in the same
situation for another feature.

I can accept the "it's too hard to implement" argument, but not "it
doesn't bring anything".

quoted

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?

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".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/