branch: Move multiple branches in a single --force #1992
Conversation
Welcome to GitGitGadgetHi @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:
You can CC potential reviewers by adding a footer to the PR description with the following syntax: NOTE: DO NOT copy/paste your CC list from a previous GGG PR's description, 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:
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 patchesBefore 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 Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a 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 curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo 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): To send a new iteration, just add another PR comment with the contents: 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, |
|
There are issues in commit 0d134a1: |
411caf2 to
79e4e6c
Compare
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. Allow moving multiple branches to a single target by giving 'git branch --force b1 b2 b3 ... dest' cp-like semantics, all the branches are moved/created to 'dest'. The convention extends the 2-args form in the same way 'cp a b c ... dest' would do. There could be another potential interpretation of `--force a b c`: moving all 3 to HEAD, but the 2-args form already changed the semantics to cp-like instead of appending an implicit HEAD, so this seems the least surprising way to support multiple moves. No such change is done to the move/copy paths, as such paths would error out anyway by trying to create multiple branches of the same name. Signed-off-by: Andrea Stacchiotti <[email protected]>
|
/allow |
|
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. |
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
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. |
No description provided.