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 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. -- Cheers, Sverre Rabbelier -- 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