Re: [PATCH 06/19] git_remote_helpers: push all refs during a non-local export

[Jonathan Nieder <jrnieder@gmail.com>]

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.