On 2008.08.23 11:56:27 -0700, Linus Torvalds wrote: > On Sat, 23 Aug 2008, Björn Steinbrink wrote: > > So, how would you make it less obscure and unobvious then the current > > method? The current method would be: > > > > git fetch linux-next > > git checkout linux-next/whatever > > > > Which seems neither obscure nor unobvious to me... > > One thing that I admit we haven't done is _document_ this in some > obvious place. One thing I experienced in #git is that people seem to have problems understanding remote tracking branches like linux-next/whatever in the above example. Quite often, there have been requests like: How can I pull into all of my branches at once? And after some back and forth about pull being fetch+merge and that you can only merge into your current branch etc. it usually turns out that those folks just have a local branch for each remote tracking branch, even if all they want is just the state of the remote tracking branch anyway. So they end up doing stuff like: git checkout foo git pull git checkout my_work_on_top_of_foo git rebase foo Where "foo" is always just fast-forwarded to origin/foo. So I think a major part of the problem is that remote tracking branches are not understood or at least not valued enough. Unfortunately, I have no real idea how we could improve that. Once on #git, I explained how branches (ie. the refs in refs/heads) are special and that HEAD becomes a symbolic ref when you check them out, while it becomes a plain reference to a commit when you check out something else (tag, remote tracking branch, commit, whatever). And that operations like commit dereference HEAD until they find a non-symbolic ref and update _that_ ref. I think that explanation worked quite well for the person I was talking to and made him realize that you only need branches when you really want create your own commits. But OTOH, telling people that local branches are the actual special case might as well confuse the hell out of them (me thinks). And besides that, I'm no good at writing "static" documentation anyway. Björn -- 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
