Re: [PATCH 2/2] rebase -i: new option --name-rev
From: Dominique Quatravaux <hidden>
Date: 2016-06-15 22:53:15
Junio C Hamano [off-list ref] writes:
quoted
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 [off-list ref] 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