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

Re: [PATCH] rebase: introduce --update-branches option

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Sep 3, 2019, 00:50 UTC
Message-ID
<20190903005018.GH11334@genre.crustytoothpaste.net>
In-Reply-To
<20190902234109.2922-1-wh109@yahoo.com>
On 2019-09-02 at 23:41:08, Warren He wrote:
Show 13 quoted lines
> Sometimes people have to rebase multiple related branches. One way to do that
> quickly, when there are branches pointing to ancestors of a later branch (which
> happens a lot if you try hard to pad your PR count on GitHub--I mean if you try
> to make small, logically separate changes), is to rebase that later branch and
> then reset ancestor branches to the rewritten commits. You just have to work
> out which branches correspond to which of the new commits.
> 
> Here's an automated way to update those ancestor branches.
> 
> It's implemented as a function that processes a todo list, modeled after
> `todo_list_add_exec_commands`. Currently steps are added as `exec git branch -f
> <branchname>`, which comes with the caveat that they're not applied atomically
> when it finishes rebasing.

This is an interesting idea, and I definitely would find myself using it. I maintain multiple nested branches for the SHA-256 transition and rebasing tends to be a bit of a hassle. The idea of reordering commits further down into earlier branches using this technique is also appealing.

I like the idea of using existing tooling for this and not needing an additional verb.

My gut tells me folks may want a bit more control over *which* branches are rebased, but I don't have a personal need for that, so I'm not going to request it or propose an interface for it. If nobody else does, then I think we should adopt the simplest approach, which is what you've proposed. Users can always edit the todo list if they find an unexpected branch, after all.

The other thought I had about this is a question about how it performs with many refs. I've worked with a repository with easily 80,000 refs, and I wonder if the current technique will perform adequately there.

I'm interested to hear others' opinions on this series and am looking forward to seeing it progress.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Previous: Phillip WoodNext: Junio C Hamano
Message 10 of 16 in “rebase: introduce --update-branches option”
  1. rebase: introduce --update-branches optionWarren He, Sep 2, 2019
  2. rebase: introduce --update-branches optionWarren He, Sep 2, 2019
  3. Johannes SchindelinSep 3, 2019
  4. rebase: introduce --update-branches optionWarren He, Sep 7, 2019
  5. rebase: introduce --update-branches optionWarren He, Sep 7, 2019
  6. Phillip WoodSep 9, 2019
  7. Johannes SchindelinSep 9, 2019
  8. Junio C HamanoSep 9, 2019
  9. Phillip WoodSep 23, 2019
  10. brian m. carlsonSep 3, 2019
  11. Junio C HamanoSep 3, 2019
  12. Taylor BlauSep 3, 2019
  13. Warren HeSep 7, 2019
  14. brian m. carlsonSep 8, 2019
  15. Phillip WoodSep 3, 2019
  16. Warren HeSep 7, 2019

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.