On 2025-02-13 at 09:43 +0000, phillip.wood123@xxxxxxxxx wrote: > 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. Makes sense, that's indeed a better use of the optional argument. Alright, I'll send a v2 with +stylistic changes and -CLI changes. -- Ivan Shapovalov / intelfx / > > > > 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 >
Attachment:
signature.asc
Description: This is a digitally signed message part
