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

Re: [PATCH] rebase: add `--update-refs=interactive`

From
Pphillip.wood123@gmail.com <phillip.wood123@gmail.com>
Date
Feb 13, 2025, 09:43 UTC
Message-ID
<8a259585-97f7-4756-a126-17a982da58d7@gmail.com>
In-Reply-To
<f0fa961084281b1d5948f59c42cf0c87e731d9bc.camel@intelfx.name>
Hi Ivan
On 12/02/2025 17:18, Ivan Shapovalov wrote:
Show 16 quoted lines
> On 2025-02-12 at 14:26 +0000, Phillip Wood wrote:
>>
>> Thanks for the explanation. So this is about copying a branch and then
>> rebasing the copy without updating the original. A while ago there was a
>> discussion[1] about excluding branches that match HEAD from
>> "--update-refs". Maybe we should revisit that with a view to adding a
>> config setting that excludes copies of the current branch from
>> "--update-refs".
> 
> This idea stops working once you have a bunch of interdependent feature
> branches (consider two branches work/myfeatureA and work/myfeatureB,
> with the latter based on the former, with each having two versions as
> described above, and then you rebase work/myfeatureB-v2 from v1 onto v2
> and expect to update work/myfeatureA-v2 but not work/myfeatureA-v1).
> Excluding branches that match HEAD is a very narrow workaround that
> only fixes one particular instance of one particular workflow.
Good point
Show 5 quoted lines
> I don't understand the opposition, really — in my understanding, an
> ability to restrict update-refs to interactive runs is a significantly
> useful mechanism that does not impose any particular policy. It answers
> the question of "I want git to _suggest_ updating refs by default, but
> only if I have a chance to confirm/reject each particular update".

I'm not opposed, I'm just trying to understand the problem and see if there are synergies with other issues people have brought to the list in the past. You've convinced me that supporting "rebase.updateRefs=interactive" is worthwhile but I do not think we want to change the commandline interface. I'd much rather reserve the optional argument to support filtering in the future so that

    git rebase --update-refs='*-v2' --update-refs=^not-me-v2

would update all the branches ending in "-v2" except "not-me-v2". We'd want configure any default patterns separately to whether "--update-refs" was enabled by default which means we can add "rebase .updateRefs=interactive" without boxing ourselves into a corner.

>> Maintaining multiple versions of the same branch sounds like a lot of
>> work - whats the advantage over merging a single branch into each release?
> 
> Different people, different workflows.
Fair enough, from what Junio said it may actually be less work anyway.
Best Wishes
Phillip
Previous: Ivan ShapovalovNext: Ivan Shapovalov
Message 14 of 16 in “rebase: add `--update-refs=interactive`”
  1. rebase: add `--update-refs=interactive`Ivan Shapovalov, Feb 10, 2025
  2. D. Ben KnobleFeb 10, 2025
  3. Ivan ShapovalovFeb 11, 2025
  4. Junio C HamanoFeb 11, 2025
  5. Ivan ShapovalovFeb 11, 2025
  6. D. Ben KnobleFeb 11, 2025
  7. D. Ben KnobleFeb 11, 2025
  8. Phillip WoodFeb 11, 2025
  9. Ivan ShapovalovFeb 11, 2025
  10. Phillip WoodFeb 12, 2025
  11. Junio C HamanoFeb 12, 2025
  12. Phillip WoodFeb 13, 2025
  13. Ivan ShapovalovFeb 12, 2025
  14. phillip.wood123@gmail.comFeb 13, 2025
  15. Ivan ShapovalovFeb 13, 2025
  16. phillip.wood123@gmail.comFeb 19, 2025

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.