Re: [PATCH] rebase: add `--update-refs=interactive`
- From
- phillip.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