Re: [PATCH 0/6] rebase: command "ref" and options --rewrite-{refs,heads,tags}

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 27, 2011, 18:36 UTC
Message-ID: <7vhb7bxgt9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <cover.1309133817.git.greg@quora.com>

Greg Price <greg@quora.com> writes:

Show 11 quoted lines

> With this series, the command
>   $ git rebase --rewrite-heads master topic
> suffices to produce this result:
>
>         part1 part2 topic
>   A       |     |     |
>    \      v     v     v
>     B--*--*--*--*--*--*
>     ^
>     |
>     master

Thanks for a re-roll.

I notice that this does not address the "side branch" issue raised during the original discussion. I do agree with Michael

  http://thread.gmane.org/gmane.comp.version-control.git/135601/focus=135617

that having some commits on these part$N side branches is far more common use case that would benefit from a "rewrite together" feature like this, than moving part$N side branches that just mark points in the topic without doing anything on their own and makes me doubt if doing only the parts that can sanely done within the limitation of the current rebase-i implementation like this series does adds much value to the system [*1*].

It would be nice to have a clear definition of what _should_ happen in this case, and a test that makes sure that that is the behaviour we get.

Starting from this topology

          1   2   topic
  A---X---Y---Z---W
   \
    B

where the change going from A to B is an equilvalent to the change going from Y to Z, a rebase of A..W would reproduce this topology:

          1   2   topic
  A---X---Y---Z---W
   \
    B---X'--Y'--W'
	    1'  topic'

What should heppen to ref2? Should it be deleted? Should it point at Y'?

[Footnote]

*1* I suspect that dealing with side branches would require a much richer implementation of the sequencer machinery that lets you go back to a previous state, which we do not have right now.

While I think that it makes your series much less interesting than the series could be that not being able to rewrite side branches, I do not think it is reasonable to expect it be done within the current rebase-i implementation/limitation.

With a richer sequencer, when you want to rebuild 'topic' along with 'side' in this picture:

            D side
           /
  A---B---C---E---F topic
   \
    X

on top of X, I would imagine that your rebase-i insn sheet would say something like this:

    detach at X
    replay B
    replay C
    replay E
    replay F
    update ref "topic" with HEAD
    detach at the rewritten C
    replay D
    update ref "side" with HEAD