Hi, On Thu, 16 Nov 2006, Junio C Hamano wrote: > I think the earlier write-up by Linus on magic HEADs would help > documenting FETCH_HEAD better. I am not sure that documenting FETCH_HEAD better would help. As Han-Wen pointed out (and some colleagues of mine who would never subscribe to a mailing list), people do not read the manual, but rather try to wrap their heads around the inner workings from the interface. And FETCH_HEAD just does not meet _any_ expectation a sane (read: untainted) user might have. While I'm at it: the problem I pointed out with -pull may annoy just me. But there is another problem with "git fetch": a common work flow is tracking other peoples branches. And since git makes it so easy to have multiple branches, chances are that you track more than one branch per remote repository. Now, an old gripe of mine was the lack of "git fetch --all". I wrote a script for that (Linus would be proud of me!), which just does "git ls-remote" and constructs a command line for "git fetch" from that. But even if you agree with the common story that you should specify the branches you want to track: it is hard! If I were new to git, after reading some tutorials I would _expect_ "git fetch" to be the tool to track branches. (I posted a patch to at least be able to store the current "git fetch" command line under a nick IIRC). But it does not. (Of course, after reading several documentation, as a new user I would eventually find that I should edit .git/remotes/<nick>, or even edit/-repo-config the remotes information in the config, but I would fully expect a new user to give up before reaching that stage.) But maybe I got it all wrong and this is not the common expectation... Ciao, Dscho - 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