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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greg Price <greg@xxxxxxxxx> writes:

> 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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]