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

[phillip.wood123@gmail.com]

Hi Ivan

On 12/02/2025 17:18, Ivan Shapovalov wrote:
> 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

> 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