Re: git-svn and huge data and modifying the git-svn-HEAD branch directly

On Wed, 1 Mar 2006, Josef Weidendorfer wrote:

On Wednesday 01 March 2006 17:24, Linus Torvalds wrote:

quoted

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