On Mon, 30 May 2011, Jonathan Nieder wrote: > Jonathan Nieder wrote: > > > | error: Ref refs/remotes/origin/master is at d94a46270250454f1fc6c1fb47abfde31a2196c9 but expected dfb79bbc658333d5c9b0427b71f6b1bc48629949 > > | From mediawiki::http://localhost/mediawiki > > | ! dfb79bb...c57c15b master -> origin/master (unable to update local ref) > > | error: Could not fetch origin > > > > which means that the transport machinery thought the helper was going > > to be fetching directly to "master". I suspect you will want a > > 'refspec' capability like > > > > refspec refs/heads/*:refs/mediawiki/${remotename}/* > > > > to fix this. > > > > Cc-ing Daniel who invented v1.7.0-rc0~62^2~19 (Allow helper to map > > private ref names into normal names, 2009-11-18). What namespace > > should a helper use when asked to fetch to FETCH_HEAD without a remote > > name, like > > > > git fetch mediawiki::testwiki > > > > ? The main purpose of having the private ref names is to support incremental imports, where you obviously need to identify the sha1 of the last thing you imported, and you may have included sufficient machine-readable information in your imported commit messages to know what the foreign state was that generated that sha1. (And you need a namespace because you may have multiple refs that you imported.) I'm not sure that it makes much sense to do incremental imports without a remote name, since that's generally an operation you're not planning do repeatedly. But the purpose of the namespacing is to be able to continue the correct incremental import, so it would make sense to do some arbitrary transformation to make your url be a valid ref directory, and use that. It would make sense to add support for a namespace where fast-import can write whatever it wants, and it'll get discarded after the fetch is done, if it's the case that anyone can stand not having incremental imports. -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