Re: [PATCH 4/5] fast-export: Introduce --inline-blobs

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Introduce a new command-line option --inline-blobs that always inlines
> blobs instead of referring to them via marks or their original SHA-1
> hash.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
>  Documentation/git-fast-export.txt |    5 +++++
>  builtin/fast-export.c             |   23 +++++++++++++++++++++--
>  2 files changed, 26 insertions(+), 2 deletions(-)

Hmm, this smells somewhat fishy.

Wasn't G-F-I designed to be a common stream format for other SCMs to
generate streams, so that importers and exporters can be written once for
each SCM to interoperate?

This patch will allow you to write an importer that can only take a stream
with inlined blobs without any references to previous occurrences, but if
the exporter for an SCM that you are trying to interoperate with does not
support --inline-blobs, you are screwed.

What is the problem you are really trying to solve?  If it is "it is
cumbersome to keep track of blob references", wouldn't it be nicer to
instead make it easier for importers to support referenced blobs?

Just thinking aloud, but is it possible to write a filter that converts an
arbitrary G-F-I stream with referenced blobs into a G-F-I stream without
referenced blobs by inlining all the blobs?  Then other people do not have
to implement --inline-blobs to their own exporter.

If that is not possible, should/can we do something to at least allow
people to check if an existing stream is compatible with an importer that
cannot take referenced blobs without actually trying to run import (and
see it fail)?  Do we need a way to encourage people to add --inline-blobs
support to their exporters?  I suspect this series leads to make G-F-I
less useful by fragmenting the compatible subset of stream formats without
such effort, no?