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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2013, 15:36 UTC
Message-ID: <7vobdfztz9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <vpqppxvoqsc.fsf@grenoble-inp.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

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.

I agree that is a good way to look at the problem and would lead to a much better design of the division of labor among these three moving parts.

Show 7 quoted lines

> It's not about fixing the existing rebase. It's about implementing
> autostash the right way.
>
> 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.

Your "rebase can do the autostash right way" idea in the other message is a good one, I think. The rebase proper will sequencially either apply patches (if the user is using the "format-patch | am" variant) or cherry-pick commits ("rebase -m"). Conceptually we can view the WIP in the working tree as just another commit at the tip of the original history to be rebased (modulo that it should not be left as a commit in the resulting history, and we may need to differentiate what was in the index and what was only in the working tree). Ignoring the "conflicts at stash pop time" issue for now, a rough outline may look like:

	git-rebase --autostash

		git commit --allow-empty -m 'index part'
	        git commit --allow-empty -a -m 'working tree part'
                git rebase --onto $UPSTREAM
                git reset HEAD^
                git reset --soft HEAD^

The first "reset" is to match the index to what was "stashed" with the first "commit" ('index part') while keeping the working tree changes the original WIP had ('working tree part'), and the last "reset --soft" is to move the HEAD back to the tip of the originally committed history.