Felipe Contreras <felipe.contre...@gmail.com> writes:
> On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> This sounds like a good thing to do. Perhaps the refspec mapping
>> can be handled the same way as a backend feature so that you do not
>> have to unconditionally disable it in the other patch.
> With my patch the remote helper doesn't need to know about the refspec
> handling at all, it just works magically.
The consumers of "git fast-export" do not need to know how to flip
refspecs when consuming output from "git fast-export", because you
taught "git fast-export" to do the mapping.
But doesn't that coin have a flip side? When somebody else (not
git) generates a fast-import stream, because these consumers are not
prepared to flip refspecs, they cannot rename while importing. All
the producers have to be taught to do the ref mapping.
I do not know if this matters in real life, and even if it did, in
the eventual ideal world, both importers and exporters would learn
to do so. So I do not think what you did in your patch is a bad
design in that sense. It is a half step in the right direction.
I however found it somewhat ugly that the interface to specify set
of refs to traverse history to find the set of objects to export
stays the same as before, and the ref-mapping arguments are bolted
on to the machinery, without having any relationship between them.
The user is free to tell it to export only 'next', while telling it
to map 'master' to 'trunk', for example.
This is an external interface that is exposed to any users of "git
fast-export", so if we go that route, we would have to keep that
interface working forever, even when later somebody else wants to
add an interface that only requires ref-mapping arguments (and infer
what is exported from the left hand side of the refspecs).
That part is what I found is less than ideal in the patch.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html