On Thu, Jun 09, 2011 at 03:09:12AM -0500, Jonathan Nieder wrote: > If we imagine that the remote helper author wants to write as little > code as possible (which seems reasonable), then probably their > "export" command will simply feed its input to a vcs-fast-import > program. git fast-export doesn't know how to do ref mapping and > neither would vcs-fast-import. So one is led to wonder which stage in > the pipeline can make the adaptations to make "git push hgrepo > HEAD:refs/heads/bar" work. Yeah, when writing the original series, I really had the thought that the remote helper would be sitting in the middle and could do the mapping. But really, not necessarily; the data is more likely to go straight to an importer. And the mapping code may be ugly, which means we want git itself to do the heavy lifting, not individual helpers. > To be friendly to remote helper authors, it would be nice to take > care of the ref mapping somewhere on the transport-helper side, unless > fast-import learns a new mode that does not label its result with > refs. In the latter case, the "export" command could look like[*] > > export :1 refs/heads/foo > export :2 refs/heads/bar > export :3 +refs/heads/force > > with :1, :2, and :3 being marks in the fast-import stream. I think we already have something like that with: reset refs/heads/foo from :1 in the import stream. And then that matches the concept that the helper is really just pushing all of the work to that VCS's fast-import stream. And _if_ we can convince fast-export to write a stream of commits that are not on any particular ref, then we could just dump the ref-mapping at the end of the export stream. There's nowhere to talk about "forced" pushing there, though. We could add in a "force" flag on that reset command. But it's not even necessarily a concept that will map to other version control systems. I wonder if it is simply something that we might have to live without when moving commits between systems. -Peff -- 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