Re: [PATCH] branch: move multiple branches in a single --force

From: Andrea Stacchiotti <andreastacchiotti@gmail.com>
Date: Jun 10, 2025, 22:17 UTC
Message-ID: <CAEgWtF-fNXaC88FWw5K_3ZpbvQSxAfeuCFy8kkrh_z16vD77=g@mail.gmail.com>
In-Reply-To: <xmqq7c1jmgpq.fsf@gitster.g>

Thank you for your review, the concerns are fair, I'll reply point-to-point.

The general issue is that AFAIK the only way git has to say: "point non-checked-out branch B to commit-ish X, leave B's config intact, if B doesn't exist create it" is `git branch --force B X`.

This is likely an abuse of `branch -f`, it might be better giving it another flag altogether, like `-p/--point-to`.

`branch --force` is massively overloaded and most of its functionality is tied to `--move` or `--copy`, so changing branch names, not repointing branches.

This patch aims to make repointing multiple branches to the same commit-ish easier, currently it needs a shell loop.

I'd like this functionality for gitops repos, where each branch is an env and I want to update dozens of envs to the last config state.

Il giorno mar 10 giu 2025 alle ore 23:25 Junio C Hamano <gitster@pobox.com> ha scritto:

Show 22 quoted lines

>
> "Andrea Stacchiotti via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Andrea Stacchiotti <andreastacchiotti@gmail.com>
> >
> > Using either the 1-arg or 2-args form of --force
> > it is possible to only move one branch at a time,
> > to HEAD and <arg2> respectively.
>
> If you are renaming (or "moving") a branch that is not checked out
> anywhere to a new name that is not in use, you do not even need to
> force.  You can just do:
>
>     git branch -m old new
>
> You are not moving branches without "-m".
>
> What you are doing is to point a branch A to point at a commit X
> with
>
>     git branch A X

Indeed, this is about repointing, not changing branch names.

Show 6 quoted lines

> Your proposed log message talks about "--force" too much; if you are
> creating a branch, you need "--force" only when the name you want to
> use is already taken.  Pointing the branch tip to a commit is not
> inherently tied to "--force", but your description gives a false
> impression that you are adding a special feature when "--force" is
> used.  The proposed log message needs rewritten.

Right, it's that I'm using "force create branch A onto X, delete A if it existed" as "repoint branch A to X, create it if needed", I likely have a skewed view on it. This usecase might be better served by a new flag.

Show 6 quoted lines

> If there is not yet a branch A, you do not even need "--force" on
> this command line.  Also take a special note that "X" does not have
> to be a branch name.  It only has to resolve to a commit, so this is
> also valid:
>
>     git branch [--force] A X~4

Yeah, it was not clear from my message, nothing about the change is about renaming a branch, my usecase is about repointing to a generic commit-ish, like you say.

Show 7 quoted lines

> I can understand that it may appear to be handy to be able to set
> multiple branches at the same time with
>
>     git branch A X~4 B X~3 C X~2                (* does not exist *)
>
> with or without "--force".  If none of A, B, or C exist, they can be
> created from these three commits X~4, X~3, and X~2.

I'm not opposed to implement this if it's preferred, but I liked the cp-like syntax as it's less repeating and the average shell user is already exposed to it via cp or mv.

Show 11 quoted lines

> Or you could propose a different syntax to create branches pointing
> at the same commit
>
>     git branch A B C origin/master              (* does not exist *)
>
> But either syntax to create multiple branches feel somewhat
> inadequate.  What should happen to their associated configuration
> data like branch.A.remote and branch.B.merge?  Should they all point
> at the same remote & a branch at the remote?  How would that make
> having multiple of them useful?
>

This is closer to the intended syntax and use of the feature, I'm more focused on branch repoints but I'd also use this when I create, say, the staging and prod env of client newclient via `git branch [-f] newclient-prod newclient-stag <commit-ish>`

The branches are useful because they are then supposed to evolve independently and track the real world state of the two envs.

If <commit-ish> is a remote branch the implementation sets up tracking, but this is really not the intended usecase, once the branches are created their remote tracking is set at push time to <default remote>/<branch name> as per default push config.

Thanks for your review, I hope my intent is clearer.