Matthieu Moy wrote:
> AFAICT, "git merge --abort" is an alias for "git reset --merge"
Yes, that is correct.
> 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 git-pull.sh 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html