Christopher Tiwald <christiwald@xxxxxxxxx> writes: > Suppose a user configured a local branch to track an upstream branch by > a different name or didn't set an upstream branch at all. In these > cases, issuing 'git pull' without specifying a remote repository or > refspec can be dangerous. In the first case, 'git pull --rebase' could > rewrite published history. In the second, 'git pull' without argument > will fail. The latter case of stopping without causing damage is hardly dangerous, so I'll ignore that for now, but I am not sure what you mean by the former. A "devel" branch has "master" from "origin" (or whatever branch.devel.remote is set) as its upstream (i.e. "devel" and "master" are different strings). "git pull" will then fetch "master" from the other side, and either merge that into "devel" or rebuild "devel" on top of it if you gave "--rebase". But if you used "master", not "devel", as the name of your local branch, I do not see anything changes. You may have published the tip of "master" to a third repository before doing "pull --rebase", and you may be rebasing the history leading to that commit. Even if there is no third repository, your "master" may be pushed to some other branch of "origin", so the story is the same. If your counter-argument is "but but but I will never ever push my 'master' to names other than 'master' at 'origin'", then in your original settings where your local branch is called "devel", you will never ever push you 'devel' to branches other than 'master' at 'origin', exactly because its upstream is set to 'master'. So what makes it dangerous is the use of "--rebase", if anything, isn't it? It does not seem to have much to do with how the local branches are named. -- 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