Re: Should --update-refs exclude refs pointing to the current HEAD?

From: Stefan Haller <lists@haller-berlin.de>
Date: Apr 20, 2023, 15:27 UTC
Message-ID: <2db5c4a5-533a-f004-cf26-7ef938d1f94d@haller-berlin.de>
In-Reply-To: <98548a5b-7d30-543b-b943-fd48d8926a33@gmail.com>

On 17.04.23 14:14, Phillip Wood wrote:

Show 16 quoted lines

> On 17/04/2023 09:21, Stefan Haller wrote:
>> Both of these cases could be fixed by --update-refs not touching any
>> refs that point to the current HEAD.
> 
>> I'm having a hard time coming up
>> with cases where you would ever want those to be updated, in fact.
> 
> If a user using stacked branches creates a new branch and then realizes
> they need to fix something on the parent before creating any commits on
> the new branch they would want both to be updated. e.g.   
>     $ git symbolic-ref HEAD
>     refs/heads/topic
>     $ git checkout -b another-topic
>     # fix a bug in topic - want topic and another-topic to be
>     # updated
>     $ git rebase -i --update-refs HEAD~2

OK, this is indeed one situation where my proposed change would do the wrong thing.

It is of course impossible for git to tell whether you were meaning to create a stack of branches here, or whether this is one of the cases where I'm creating a copy of a branch and want to "detach" it from its source branch, as in the examples I posted earlier in this thread.

In my personal experience the latter is much more common than the former, and it's also easier to correct the mistake manually in your example by hard-resetting one branch to the other again, so I still think it would be a useful change.

Any other opinions about this?

-Stefan