Am 3/8/2012 23:13, schrieb Junio C Hamano: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Thomas Rast <trast@xxxxxxxxxxx> writes: >> >>> Dominique Quatravaux <domq@xxxxxxxxxx> writes: >>> >>>> 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 -- 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