git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Mar 9, 2012, 07:22 UTC
Message-ID
<4F59AFA9.5030205@viscovery.net>
In-Reply-To
<7vipiebv1r.fsf@alter.siamese.dyndns.org>
Am 3/8/2012 23:13, schrieb Junio C Hamano:
Show 29 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Thomas Rast <trast@inf.ethz.ch> writes:
>>
>>> Dominique Quatravaux <domq@google.com> 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
Previous: Junio C HamanoNext: Dominique Quatravaux
Message 9 of 18 in “rebase -i: optimize the creation of the todo file”
  1. 1/2 rebase -i: optimize the creation of the todo fileDominique Quatravaux, Mar 8, 2012
  2. 2/2 rebase -i: new option --name-revDominique Quatravaux, Mar 8, 2012
  3. Thomas RastMar 8, 2012
  4. Dominique QuatravauxMar 8, 2012
  5. Junio C HamanoMar 8, 2012
  6. Dominique QuatravauxMar 9, 2012
  7. Junio C HamanoMar 8, 2012
  8. Junio C HamanoMar 8, 2012
  9. Johannes SixtMar 9, 2012
  10. Dominique QuatravauxMar 9, 2012
  11. Junio C HamanoMar 9, 2012
  12. Thomas RastMar 8, 2012
  13. Dominique QuatravauxMar 8, 2012
  14. Thomas RastMar 8, 2012
  15. Johannes SixtMar 8, 2012
  16. Dominique QuatravauxMar 8, 2012
  17. Dominique QuatravauxMar 8, 2012
  18. Johannes SixtMar 8, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.