Ryan Lortie <desrt@xxxxxxxx> writes: > In this case, the user wanted to checkout a branch of a module. They did: > > git clone git://git.gnome.org/gtk+ > cd gtk+ > git branch gtk-3-4 > > Obviously this is a user error, but it's a pretty innocent one, and > puts the user in a bad state. When they figure they should have typed > "git checkout gtk-3-4" it is already too late -- they will be taken > onto their locally-created copy of the master branch. > > So feature request: 'git branch' should not allow creating a local > branch that has the same name as a branch that already exists on > origin' (or any remote?) without some sort of --force flag. I think "the same name" is missing the point. It is perfectly fine to have your own 'fix' branch that builds on top of what the remote side calls 'master', with the intention of testing what you queue on your 'fix' branch locally and cherry-picking proven-good ones to your 'master' before pushing the result out, even when there happens to be a 'fix' branch that your 'fix' branch does not have anything to do with on the remote side. After all, the remote side may start using the 'fix' branch _long_ _after_ you start using your 'fix' branch, so checking at the branch creation time does not help you much, even if it were a problem that your local 'fix' (which you have no intention to push it to the remote) and the 'fix' at the remote does not have any common purpose. The same can be said for the gtk-3-4 branch, depending on the purpose of 'master' vs purpose of 'gtk-3-4' at the remote side. If 'gtk-3-4' branch were the playground to come up with the next great version, and 'master' is the continuation of the current version with not so earth-shattering changes, it is perfectly normal for different contributors to fork from 'master' for their next feature that they hope eventually to go to 'gtk-3-4' at the remote, and locally name the branch 'gtk-3-4', build their feature, and depending on how disruptive the change is, choose to integrate the result into either 'master' or'gtk-3-4' at the remote after it is done. So it is not immediately clear if "git branch gtk-3-4" in the example is a problem to begin with. Given that "git checkout gtk-3-4" with recent enough Git (since 1.7.0) DWIMs the command to do the equivalent of git checkout -t gtk-3-4 origin/gtk-3-4 that is, to fork, build on top of, and to be integrated with the 'gtk-3-4' branch at the 'origin', if you know with a reasonable degree of certainty that the user should have typed "git checkout gtk-3-4" when he typed "git branch gtk-3-4" in the example, then it could be argued that "git branch" could offer an advice message, but it is unclear how you can be sure if "git checkout gtk-3-4" was what the user really wanted to do when he said "git branch gtk-3-4" in the first place. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html