Re: [PATCH 2/2] rebase -i: new option --name-rev

From: Dominique Quatravaux <domq@google.com>
Date: Mar 9, 2012, 09:04 UTC
Message-ID: <CAJh6GrGEix8qfAuJamWzcr69=LjkZ-O9B=Vorvy_KTcJe3TcPA@mail.gmail.com>
In-Reply-To: <4F59AFA9.5030205@viscovery.net>

Junio C Hamano <gitster@pobox.com> writes:

Show 5 quoted lines

>> Today's "git rebase -i" wouldn't do something like that, and we will
>> not know how the user would interact with such a yet-to-be-written
>> tool, so it is too early to judge if using "topic~1" is the desired
>> improvement or not at this point.
>

On Fri, Mar 9, 2012 at 8:22 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:

> Yet-to-be-written? Rebase -i happily linearizes mergy history, so this
> does have some merits even today.

Right, my personal itch is to "transplant" topic branches without their merge history getting in the way, eg go from

   M1 ------ M2 ----- M3 ---- M4                master
     \                  \
      \           B1 --- B2 --- B3              topicB
       \         /
        A1 --- A2 --- A3                        topicA

to

   M1 ---- M2 ---- M3 ---- M4                   master
     \                       \
      \                       B1 ---- B3        topicB
       \
        A1 ---- A2 ---- A3                      topicA

If I "git rebase -i --onto master topicA topicB", the rebase todo might go like

  pick 1234abc Cool shiny new stuff
  pick 234abc1 Something something master
  pick 34abc12 Fix something something
  pick 4abc123 Fix shiny new stuff

With my patch (combined with Junio's suggestion, and some whitespace padding for extra niceness) we would get instead

  pick 1234abc (topicB~2) Cool shiny new stuff
  pick 234abc1 (master~2) Something something master
  pick 34abc12 (master~1) Fix something something
  pick 4abc123 (topicB)   Fix shiny new stuff

Snip the lines that don't m/topicB/ with your text editor, save file, done.

> I do share your concerns that naming to-be-rebased commits with a relative
> specifier such as "topic~1" could be dangerous. However, this is a problem
> only when the rebase -i is not completed timely, so that you have
> sufficient time to mess with the ref "topic" from a different terminal.

I think that Junio's suggestion fixes that (at the expense of 8 of the precious 80 columns).

--
  Dominique Quatravaux
  +41 79 609 40 72