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
