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

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Apr 17, 2023, 08:34 UTC
Message-ID: <d3895d9b-b45a-449d-a5e6-b8b8c5e6c4b8@app.fastmail.com>
In-Reply-To: <adb7f680-5bfa-6fa5-6d8a-61323fee7f53@haller-berlin.de>

Hi

On Mon, Apr 17, 2023, at 10:21, Stefan Haller wrote:

Show 7 quoted lines

> 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? I would keep the tag around and then branch off of that if I want to make another divergent history in the future.

This is interesting to me since copying branches indeed does not seem to *gel* with this git-rebase(1) option. But I never really understood the use-case for copying branches rather than using lightweight tags.

† 1: I wonder why it wasn’t called `--update-branches`. On the one hand,
    the option ignores refs other than branches. On the other hand, the
    command in the todo list *will* update tags if you tell it to, and
    even refs like `/refs/notes/*`. But `--update-branches` seems like a
    better name, at least outside the todo editor.

-- 
Kristoffer Haugsbakk