Jeff King wrote (2008-04-09 18:51 -0400): > On Thu, Apr 10, 2008 at 01:25:00AM +0300, Teemu Likonen wrote: > > > Another thing I spoke of was this refs/ stuff. I know my way around > > with them now, so maybe they are not actually confusing to me > > anymore. It's just that I have noticed a pattern: I always use > > refs/heads/... in certain places and refs/remotes/ in certain > > places. If such a pattern is very common (well, I don't know if it > > is) one starts to think that maybe the pattern can/should be hidden > > and made part of the tool. Just thoughts. > > I almost never use refs/remotes/ or refs/heads/. Some effort has been > put into doing the right thing with partial refnames (which you can of > course override by being more specific). Do you have specific examples > of where you use the full refname? I suspect it is either not required > (and documentation may be out of date), or it is a bug we could fix. > :) In real work I have used refs/heads/...:refs/remotes/... only once or maybe twice (I just quite recently started using Git). But when I studied Git and the workflows it supports I tried all kinds of fetching, pulling and pushing, back and forth, between test repos. There I used refs/ paths a lot, almost all the time actually. At first it was very much just trying to see how they work and this is where I found this common pattern: local refs start with refs/heads/ and remote tracking ones with refs/remotes/ . Thoughts like "why not simplify them, like L: for local and R: for remote" (or something) started to develop. Now it seems that I have been too much attached to the full refspec form. My guide have been the config remote.<name>.fetch as "git remote add" adds those long refspecs. Now I learnt that almost all refspecs can be written as "branch:another" or "branch:remotes/another" for example. So the "friendly refspecs" are pretty much already there! Well, I've been stupid. :) (I understand that in real work when constantly dealing with same remote repos one just adds a remote config and can forget about URLs and probably most of the refspecs too.) Ok, this was partly an RTFM error but even after reading man pages of fetch, pull and push it isn't quite clear how to use these short and nice and friendly refspecs. I thought about it and decided to add some more examples to fetch manual (see my patch in the next message). My English may not be manual-writing quality but I wanted to do something useful anyway. Somebody needs to proof read my text though. Of course there may be some inaccuracies too. Anyway, I think that concrete examples in manuals help people to understand Git better. There is still one thing (at least) that I don't quite understand. It's about "git push". When I do $ git push <remote> <branch> the refs/heads/<branch> is updated or created on the remote side. But if I do $ git push <remote> <branch1>:<branch2> the refs/heads/<branch2> is not automatically created. Why there is need to say "<branch1>:refs/heads/<branch2>" to make it work if <branch2> does not exist? The 'git push' manual says something vague about branch not matching (?). What does it mean? -- 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
