Re: [PATCH v2 09/13] Honour the refspec when updating refs after import

On Thu, 5 Nov 2009, Sverre Rabbelier wrote:

Heya,

On Wed, Nov 4, 2009 at 22:30, Daniel Barkalow [off-list ref] wrote:

quoted

On Wed, 4 Nov 2009, Sverre Rabbelier wrote:

quoted

On Wed, Nov 4, 2009 at 22:20, Daniel Barkalow [off-list ref] wrote:

quoted

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.

quoted

quoted

quoted

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*