Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > 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. > > How does this fit with the fact that git has forever(?) created a > 'master' branch when cloning, and usually points it at origin/master > too? A big difference is that it by default is set to integrate with origin/master. > I honestly haven't decided whether I should like or hate your proposal, > but ISTM that outlawing an operation that git does on every clone is a > bit moot. I am sympathetic to this particular example of the user regretting that he has said "git branch" when he meant "git checkout", and also am sympathetic to the wish that "git branch" somehow figured out the situation and offered an advice, or outsmarted the user and forbade the operation. But I do not think "git branch" can sensibly and correctly make that decision for the user---at least I do not sense any of the people who is in this thread has clear idea on what to base that decision on, and "the same name appears in an existing remote" is not it. "The same name appears, and the new branch is not set to integrate with it" may be closer, but that may forbid valid use cases too much. -- 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