Han-Wen Nienhuys <hanwen@xxxxxxxxx> writes: > Junio C Hamano escreveu: >>... >> Sigh indeed. >> >> Why don't you do the simple and obvious >> >> git pull url master > > It is not all evident from the git-pull man-page that this is the > obvious and most common usage. In the git user poll a few months ago, many people recommended "everyday git" as a good cheat sheet, and indeed it does not talk anything about directing the underlying git-fetch to manipulate tracking branches by giving explicit refspec pairs to git pull. You are obviously tripped by both the overeager manpage (but manpage should strive to be complete so you cannot really blame it) and less than optimally organized tutorial style documents. I myself do prefer, when learning a new tool, to use longhand until I understand the shorthand, but that attitude requires a true commitment to learn the tool, and most people do not go that route. Tutorial style documents tend to give the commonly used shorthand first for that exact reason. Shorthand to give only the branch name to fetch and merge immediately without using a tracking branch is equivalent to longhand "branch:" as you found out, so if that was what was desired then people with the attitude "before understanding what longhand does I prefer using shorthand" like myself and you would have liked to learn "git pull url branch:" notation from Tutorial. But I think we _are_ minority. People would not want to see that seemingly useless colon there. > To me it's very unlogical that > > master:current-branch > > doesn't work, That shows that you did not understand what fetch does. Maybe you do now, but a very natural consequence of directing fetch to update tracking branches with the colon notation is: - "pull url master:master", while on master, is almost always wrong and not something you would want to do, ever. "fetch --update-head-ok url +master:master; reset --hard HEAD" may make sense but never "pull". > I use the remote:local syntax, because I started using GIT in scripted > compiles from copied branches of remote repositories. There the > explicit remote:local statements are necessary because there is no > default branch. If you perhaps wanted to ask "is there a better way to do what I've been doing?", then I am willing to think with you to come up with an answer. Unfortunately, however, I do not understand the above paragraph, so I'd refrain from commenting on it in this response. - 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