On Thu, 5 Nov 2009, Sverre Rabbelier wrote: > Heya, > > On Wed, Nov 4, 2009 at 22:30, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > > On Wed, 4 Nov 2009, Sverre Rabbelier wrote: > >> On Wed, Nov 4, 2009 at 22:20, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote: > >> > That's not true for "git pull <url> <branch>"; we do want the remote ref, > >> > but it doesn't have a local peer. > > No, I don't think that's right, when doing a fetch we want to store > the refs somewhere, sure, but not under 'refs/heads/<branch>', perhaps > 'refs/hg/fetch/<branch>', either way, the current code does not work. I think you've still got things backwards. From the point of view of transport.c, refs/<vcs> is entirely opaque, and we never look at it. Those aren't local peers. They're a way for the helper to communicate to transport-helper.c. The user says: pull refs/heads/master of this hg repo. Transport.c tries to fetch refs/heads/master and get the sha1 to write into FETCH_HEAD or wherever. Transport-helper.c says "import refs/heads/master", and git-fast-import reads the resulting script and writes some ref that the helper tells it to write. Then transport-helper.c figures out where the ref was written, reads it, and updates the struct ref representing the remote info. Then builtin-fetch looks at the struct ref and writes it to the local repositories ref namespace or FETCH_HEAD. > >> >I think going straight to the refspec > >> > command is the right answer. > >> > >> Can you clarity what you mean with "the refspec command"? > > > > Whatever it is that lets the helper tell the transport code where in the > > helper's private namespace to look for refs. I'd been thinking the helper > > would advertize the "refspec" capability, and the transport code would > > call the "refspec" command in order to get the helper to report that; but > > then I actually only said that the helper reports refspec, and not > > proposed a name for the command. > > Currently I'm implementing so that it would work like this for the svn helper: > > $ echo capabilities | git remote-svn origin /path/to/hg/repo > import > refspec +refs/trunk:refs/svn/origin/trunk > refspec +refs/branches/*:refs/svn/origin/* > > That way we can put the refspec in the config file at clone time. > > Now I've been browsing through the builtin-fetch code, and it looks > like the main problem is going to be to apply this refspec at all. > I'll have a more extensive look tomorrow. This is entirely not what I think we should have. The config file should say refs/heads/*:refs/remotes/origin/* like it always does, because the transport will list the refs like refs/heads/* and refs/tags/* and return them like that. I'll see if I can write up an untested patch that does what I'm thinking of. -Daniel *This .sig left intentionally blank* -- 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