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@xxxxxxxxx> ha scritto: > > "Andrea Stacchiotti via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > From: Andrea Stacchiotti <andreastacchiotti@xxxxxxxxx> > > > > 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. > 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. > 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. > 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. > 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.
