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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 15, 2013, 13:56 UTC
Message-ID: <CALkWK0nqrw7DFQSnMvULYjJtBHRnadKWqCLQOAjzJH0o7USo+A@mail.gmail.com>
In-Reply-To: <vpqppxvoqsc.fsf@grenoble-inp.fr>

Matthieu Moy wrote:

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

Yes, that is correct.

Show 5 quoted lines

> 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 git-pull.sh uniform means that we have to fall back to the least-common-denominator of functionality (which is currently pull-rebase).

Show 7 quoted lines

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