Re: remote helpers: best practices for using the "refspec" capability

On Mon, 30 May 2011, Jonathan Nieder wrote:

Jonathan Nieder wrote:

quoted

| 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*