git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Daniel Barkalow <barkalow@iabervon.org>
Date
May 30, 2011, 17:43 UTC
Message-ID
<alpine.LNX.2.00.1105301300520.2233@iabervon.org>
In-Reply-To
<20110530164013.GG10879@elie>
On Mon, 30 May 2011, Jonathan Nieder wrote:
Show 23 quoted lines
> 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*
Previous: Jonathan NiederNext: Sverre Rabbelier
Message 8 of 15 in “Git fast-import : Warning duplicated ref: refs/remotes/origin/master”
  1. Jérémie NIKAESMay 29, 2011
  2. Jonathan NiederMay 29, 2011
  3. Jérémie NIKAESMay 30, 2011
  4. Jonathan NiederMay 30, 2011
  5. Jérémie NIKAESMay 30, 2011
  6. Documentation: do not misinterpret refspecs as bold text (Re: Git fast-import : Warning duplicated ref: refs/remotes/origin/master)Jonathan Nieder, May 30, 2011
  7. remote helpers: best practices for using the "refspec" capabilityJonathan Nieder, May 30, 2011
  8. Daniel BarkalowMay 30, 2011
  9. Sverre RabbelierMay 30, 2011
  10. Jonathan NiederMay 30, 2011
  11. Matthieu MoyMay 30, 2011
  12. Jérémie NIKAESMay 30, 2011
  13. Jonathan NiederMay 30, 2011
  14. Jérémie NIKAESMay 30, 2011
  15. Sverre RabbelierMay 30, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.