Junio C Hamano [off-list ref] writes:
Thomas Rast [off-list ref] writes:
quoted
Dominique Quatravaux [off-list ref] writes:
quoted
If set, the second column of the rebase todo contains named revisions (obtained
with git name-rev) instead of short SHA1s.
Hum. I'm not sure yet if I find that very useful, since frequently the
names will just be 'topic', 'topic~1', ...., 'topic~N' if you are
rebasing a topic with N+1 commits not in master. But you might, so who
am I to judge.
I think the only use case where this might be useful is when you
have totally undescriptive one-line description to your commits that
they alone do not help distinguishing the commits being picked, e.g.
...
This may need a bit of clarification for readers from the future.
If you _were_ somehow interactively rebasing changes made on two or
more branches into a single branch, knowing which branch each commit
came from may have value, even if your commit titles are descriptive
enough.
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.
Am 3/8/2012 23:13, schrieb Junio C Hamano:
Junio C Hamano [off-list ref] writes:
quoted
Thomas Rast [off-list ref] writes:
quoted
Dominique Quatravaux [off-list ref] writes:
quoted
If set, the second column of the rebase todo contains named revisions (obtained
with git name-rev) instead of short SHA1s.
Hum. I'm not sure yet if I find that very useful, since frequently the
names will just be 'topic', 'topic~1', ...., 'topic~N' if you are
rebasing a topic with N+1 commits not in master. But you might, so who
am I to judge.
I think the only use case where this might be useful is when you
have totally undescriptive one-line description to your commits that
they alone do not help distinguishing the commits being picked, e.g.
...
This may need a bit of clarification for readers from the future.
If you _were_ somehow interactively rebasing changes made on two or
more branches into a single branch, knowing which branch each commit
came from may have value, even if your commit titles are descriptive
enough.
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.
Yet-to-be-written? Rebase -i happily linearizes mergy history, so this
does have some merits even today.
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.
You would have to run "git branch -f", "git fetch", or "git push" (the
latter could even happen from remote) that involve the ref name. Can't we
just declare this as "don't do that then"? (We do say this more often than
not since recently :-)
-- Hannes
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