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

From: Stefan Haller <lists@haller-berlin.de>
Date: Apr 17, 2023, 09:22 UTC
Message-ID: <6a8b92d8-5b86-9cf3-3619-4c8bedfa2d47@haller-berlin.de>
In-Reply-To: <d3895d9b-b45a-449d-a5e6-b8b8c5e6c4b8@app.fastmail.com>

On 17.04.23 10:34, Kristoffer Haugsbakk wrote:

Show 14 quoted lines

> Hi
> 
> On Mon, Apr 17, 2023, at 10:21, Stefan Haller wrote:
>> 2. I have a topic branch, and I want to make a copy of it to make some
>> heavy history rewriting experiments. Again, my interactive rebases would
>> always rebase both branches in the same way, not what I want. In this
>> case I could work around it by doing the experiments on the original
>> branch, creating a tag beforehand that I could reset back to if the
>> experiments fail. But maybe I do want to keep both branches around for a
>> while for some reason.
> 
> I would use a lightweight tag, too, since this option doesn’t touch tags.[1]
> 
> Why do you want to keep both branches around?

Several reasons:

Maybe the original branch was pushed already, and I'm collaborating on it with a coworker. At the same time, I want to run my rebase experiment in parallel on a copy.

Maybe I want to create github PRs for both of them, in order to run CI on them, or get feedback for both of them from my coworkers.

Also, it just seems to be the most natural workflow for many people. I have seen my coworkers do this a lot without thinking much whether there would be a better way.

My question is not so much whether copying branches is a good idea, it's more about how --update-refs should deal with copied branches *if* you decide to use them.

-Stefan