Jeff King wrote: > If we do a fix that allows "refs/heads/foo:refs/heads/bar", then it > should also properly allow "+refs/heads/foo:refs/heads/bar". Which I > think means changing the single "export" command in the ref-helper to > something like: > > export refs/heads/foo > export refs/heads/foo:refs/heads/bar > export +refs/heads/force Thanks for explaining. The spirit of what you're saying seems right, so I'd like to spell it out a little to make sure. 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. 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. In the former case, the transport-helper could arrange for a stream that sets up refs/heads/foo, refs/heads/bar, and refs/heads/force to be written to stdout, but there would need to be a way to mention in the stream that the update to refs/heads/force is allowed to be non fast-forward. fast-import has a --force option for that, which unfortunately can't be controlled ref by ref. Which is all a long way to say, I think you're right and that something like the syntax marked with [*] would be nice. -- 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