Junio C Hamano <gitster@xxxxxxxxx> writes:
>> 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@xxxxxxxxxxxxx> 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
--
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