With Git 2.15 (Q4 2017), "git branch" learned "-c/-C" to create a new branch by copying an existing one.
See commit c8b2cec (18 Jun 2017) by Ævar Arnfjörð Bjarmason (avar).
See commit 52d59cc, commit 5463caa (18 Jun 2017) by Sahil Dua (sahildua2305).
(Merged by Junio C Hamano -- gitster -- in commit 3b48045, 03 Oct 2017)
branch: add a--copy(-c) option to go with--move(-m)Add the ability to
--copya branch and its reflog and configuration, this uses the same underlying machinery as the--move(-m) option except the reflog and configuration is copied instead of being moved.This is useful for e.g. copying a topic branch to a new version, e.g.
worktowork-2after submitting theworktopic to the list, while preserving all the tracking info and other configuration that goes with the branch, and unlike--movekeeping the other already-submitted branch around for reference.
Note: when copying a branch, you remain on your current branch.
As Junio C Hamano explains, the initial implementation of this new feature was modifying HEAD, which was not good:
When creating a new branch
Bby copying the branchAthat happens to be the current branch, it also updatesHEADto point at the new branch.
It probably was made this way because "git branch -c A B" piggybacked its implementation on "git branch -m A B",This does not match the usual expectation.
If I were sitting on a blue chair, and somebody comes and repaints it to red, I would accept ending up sitting on a chair that is now red (I am also OK to stand, instead, as there no longer is my favourite blue chair).But if somebody creates a new red chair, modelling it after the blue chair I am sitting on, I do not expect to be booted off of the blue chair and ending up on sitting on the new red one.