Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:
> 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html