Re: git rebase --interactive commits order
- From
Richard Peterson <richard@rcpeterson.com>
- Date
- May 11, 2011, 18:39 UTC
- Message-ID
- <BANLkTik3i8rcgDSo4A9nQjnvr-gWmnkpmQ@mail.gmail.com>
- In-Reply-To
- <7v39klgng7.fsf@alter.siamese.dyndns.org>
On Wed, May 11, 2011 at 1:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Richard Peterson <richard@rcpeterson.com> writes: > >> On Tue, May 10, 2011 at 7:26 PM, Junio C Hamano <gitster@pobox.com> wrote: >>> >>> Devils lie in the details. For example, should squash/fixup come before >>> or after the squashed commit when --reverse is in effect, and why? >>> >>> Should "rebase --reverse --continue" work after it gets interrupted, if >>> not why not? >> >> Yes, it should work,... >
[...]
Show 5 quoted lines
> > You start 'rebase' (without --reverse); it stops with conflict. Now what > should happen when you say 'rebase --reverse --continue' now? Does it > error out because you are not allowed to change your mind once you > started?
It just continues. "--reverse" is noise here. "--reverse" would only matter in the display of the initial list. It's just as much noise here as '--interactive' would be noise here, like 'rebase --interactive --continue'.
> [...] Why spend extra effort only to introduce something confusing?
Because for some group of people, you are introducing something less confusing. I have a hunch that some people see the *process* as the primary artifact, and thus things make sense just as they are. Others see the *tree* as the primary artifact, and want too see the transformation that will be attempted on the tree - but interactive rebase has the tree upside down.
I have absolutely no support for this theory other than that I find myself in the second group of people however small or large that group may be. I conceive of a rebase as a transformation of the tree, rather than a set of discrete steps. Tools that help me work with that abstraction are going to be easier for me and others like me.
-Richard