Ramkumar Ramachandra <artag...@gmail.com> 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:

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

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

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

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

Matthieu Moy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to