On Wed, 1 Mar 2006, Josef Weidendorfer wrote: > > On Wednesday 01 March 2006 17:24, Linus Torvalds wrote: > > The thing about it being .git/refs/heads/svn/xyzzy is that then you can do > > > > git checkout svn/xyzzy > > > > and start modifying it. Which is exactly against the point: the thing is > > _not_ a branch and you must _not_ commit to it. > > > > It's much more like a tag: it's a pointer to the last point of an > > svn-import. > > Isn't it the same with tracked branches of a remote git repo? > With this reasoning, all heads that git-clone clones aside from the > special "master" should not be under .git/refs/heads, but better > under .git/refs/remotes/<remoteRepoName>/ ? Yes, I think that would make tons of sense. > <remoteRepoName> is "origin" in the case of git-clone, so .git/remotes/origin > would contain > URL: http://host/repo.git > Pull: master:remotes/origin/master > > Then there would not be the need for the confusing special branch "origin" > after cloning, as namespaces are separate. I think that would make things a lot more flexible, and yes, it sounds like a good idea. HOWEVER. I think it's not only very common, but quite useful, to do what we do now, ie git log origin.. to see "what is in origin but not in HEAD". So there's a big usability issue: I don't think it's good to have to say git log remotes/origin/master.. to do the same. So from a usability standpoint, we'd have to teach "get_sha1()" about parsing .git/remotes/* files if it cannot find a branch or a tag with that name (which it wouldn't be able to, since even if it were to walk the directories udner .git/refs/ recursively, it would be named "master" there). But if somebody does the get_sha1() magic, and Junio agrees, then I think it would be a great thing to do. Linus - : 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