git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 19, 2011, 19:50 UTC
Message-ID
<7vtyh4smer.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1295415899-1192-5-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 9 quoted lines
> 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?

Previous: Ramkumar RamachandraNext: Jonathan Nieder
Message 8 of 18 in “Towards a Git-to-SVN bridge”
  1. 0/5 Towards a Git-to-SVN bridgeRamkumar Ramachandra, Jan 19, 2011
  2. 1/5 date: Expose the time_to_tm functionRamkumar Ramachandra, Jan 19, 2011
  3. 2/5 vcs-svn: Start working on the dumpfile producerRamkumar Ramachandra, Jan 19, 2011
  4. Junio C HamanoJan 22, 2011
  5. Ramkumar RamachandraJan 22, 2011
  6. 3/5 Build an svn-fi target in contrib/svn-feRamkumar Ramachandra, Jan 19, 2011
  7. 4/5 fast-export: Introduce --inline-blobsRamkumar Ramachandra, Jan 19, 2011
  8. Junio C HamanoJan 19, 2011
  9. Jonathan NiederJan 19, 2011
  10. Ramkumar RamachandraJan 20, 2011
  11. Jonathan NiederJan 20, 2011
  12. Ramkumar RamachandraJan 20, 2011
  13. Drew NorthupJan 20, 2011
  14. Ramkumar RamachandraJan 22, 2011
  15. Jonathan NiederJan 22, 2011
  16. Jonathan NiederJan 20, 2011
  17. Junio C HamanoJan 22, 2011
  18. 5/5 vcs-svn: Add dir_cache for svnloadRamkumar Ramachandra, Jan 19, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.