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

["Kristoffer Haugsbakk" <code@khaugsbakk.name>]

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? 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