git
branch: Move multiple branches in a single --force
Welcome to GitGitGadget
Hi @12345ieee, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.
Please make sure that either:
- Your Pull Request has a good description, if it consists of multiple commits, as it will be used as cover letter.
- Your Pull Request description is empty, if it consists of a single commit, as the commit message should be descriptive enough by itself.
You can CC potential reviewers by adding a footer to the PR description with the following syntax:
CC: Revi Ewer <[email protected]>, Ill Takalook <[email protected]>
NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, because it will result in a malformed CC list on the mailing list. See example.
Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
- the lines should not exceed 76 columns,
- the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
- the commit messages' body should be describing the "why?" of the change.
- Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.
Contributing the patches
Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:
Both the person who commented /allow and the PR author are able to /allow you.
An alternative is the channel #git-devel on the Libera Chat IRC network:
<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!
Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.
If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.
After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).
If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:
curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt
To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):
Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...
To send a new iteration, just add another PR comment with the contents: /submit.
Need help?
New contributors who want advice are encouraged to join [email protected], where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.
You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.
![gitgitgadget-git[bot] avatar](https://avatars.githubusercontent.com/in/46807?v=4 "Published by a pub.dev verified publisher"){kind=small}
There are issues in commit 0d134a1c203e78e28a0fd26142fdf9a5cd711818:
branch: Move multiple branches in a single --force
Prefixed commit message must be in lower case
User 12345ieee is now allowed to use GitGitGadget.
WARNING: 12345ieee has no public email address set on GitHub; GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.
Submitted as [email protected]
To fetch this version into FETCH_HEAD:
git fetch https://github.com/gitgitgadget/git/ pr-git-1992/12345ieee/master-v1
To fetch this version to local tag pr-git-1992/12345ieee/master-v1:
git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-1992/12345ieee/master-v1
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Andrea Stacchiotti via GitGitGadget" <[email protected]>
writes:
> From: Andrea Stacchiotti <[email protected]>
>
> 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
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.
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
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 comits X~4, X~3, and X~2.
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?
On the Git mailing list, Andrea Stacchiotti wrote (reply to this):
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
<[email protected]> ha scritto:
>
> "Andrea Stacchiotti via GitGitGadget" <[email protected]>
> writes:
>
> > From: Andrea Stacchiotti <[email protected]>
> >
> > 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.
On the Git mailing list, Junio C Hamano wrote (reply to this):
Andrea Stacchiotti <[email protected]> writes:
> This patch aims to make repointing multiple branches to the same commit-ish
> easier, currently it needs a shell loop.
Or "update-ref --stdin"?
On the Git mailing list, Andrea Stacchiotti wrote (reply to this):
Il giorno mer 11 giu 2025 alle ore 02:22 Junio C Hamano
<[email protected]> ha scritto:
>
> Andrea Stacchiotti <[email protected]> writes:
>
> > This patch aims to make repointing multiple branches to the same commit-ish
> > easier, currently it needs a shell loop.
>
> Or "update-ref --stdin"?
I learned something new, but I'd still like to keep advocating for a syntax
like `branch --some-flag A B C X` instead of feeding by hand
update-ref commands.
On the Git mailing list, Junio C Hamano wrote (reply to this):
Andrea Stacchiotti <[email protected]> writes:
> Il giorno mer 11 giu 2025 alle ore 02:22 Junio C Hamano
> <[email protected]> ha scritto:
>>
>> Andrea Stacchiotti <[email protected]> writes:
>>
>> > This patch aims to make repointing multiple branches to the same commit-ish
>> > easier, currently it needs a shell loop.
>>
>> Or "update-ref --stdin"?
>
> I learned something new, but I'd still like to keep advocating for a syntax
> like `branch --some-flag A B C X` instead of feeding by hand
> update-ref commands.
I am personally not interested in such a mode, I do not know why you
think "--some-flag" is needed when the command can figure out from
the number of things on the command line being more than 2 just
fine.
But my comment was targetted against "it needs a shell loop" in the
justification in the proposed log message, which is not quite
correct.
On the Git mailing list, Andrea Stacchiotti wrote (reply to this):
So, if I may ask, is the proposed patch as written (branch -f A B C X)
acceptable and you just need me to rewrite the commit message
or are you not interested in it at all?
Il giorno mer 11 giu 2025 alle ore 17:26 Junio C Hamano
<[email protected]> ha scritto:
>
> Andrea Stacchiotti <[email protected]> writes:
>
> > Il giorno mer 11 giu 2025 alle ore 02:22 Junio C Hamano
> > <[email protected]> ha scritto:
> >>
> >> Andrea Stacchiotti <[email protected]> writes:
> >>
> >> > This patch aims to make repointing multiple branches to the same commit-ish
> >> > easier, currently it needs a shell loop.
> >>
> >> Or "update-ref --stdin"?
> >
> > I learned something new, but I'd still like to keep advocating for a syntax
> > like `branch --some-flag A B C X` instead of feeding by hand
> > update-ref commands.
>
> I am personally not interested in such a mode, I do not know why you
> think "--some-flag" is needed when the command can figure out from
> the number of things on the command line being more than 2 just
> fine.
>
> But my comment was targetted against "it needs a shell loop" in the
> justification in the proposed log message, which is not quite
> correct.
>
On the Git mailing list, Junio C Hamano wrote (reply to this):
Andrea Stacchiotti <[email protected]> writes:
> So, if I may ask, is the proposed patch as written (branch -f A B C X)
> acceptable and you just need me to rewrite the commit message
> or are you not interested in it at all?
As I said, I personally am not interested in such a mode, but you
may be able to interest other people in it, and with wider support
I may change my mind. But I do not think the feature should not be
tied to "--force" option at all. "git branch A B C X" should be
able to create three new branches A B C that all tracks X if none of
them exist without "--force".
On the Git mailing list, Junio C Hamano wrote (reply to this):
Junio C Hamano <[email protected]> writes:
> I may change my mind. But I do not think the feature should not be
> tied to "--force" option at all.
Sorry for a double-negation failure. What I think is that the
feature should be orthogonal to "--force".
On the Git mailing list, Andrea Stacchiotti wrote (reply to this):
Il giorno gio 12 giu 2025 alle ore 17:48 Junio C Hamano
<[email protected]> ha scritto:
>
> Junio C Hamano <[email protected]> writes:
>
> > I may change my mind. But I do not think the feature should not be
> > tied to "--force" option at all.
>
> Sorry for a double-negation failure. What I think is that the
> feature should be orthogonal to "--force".
No worries, I got it, it makes sense.
I can implement the revised request if I see some replies expressing interest.