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

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