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

Re: [PATCH 4/4] fast-import: only store commit objects

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 7, 2013, 07:07 UTC
Message-ID
<CAMP44s1Y6rjyKZ_CGWJJ81s16DTu7cqKeFY48J_ndzpp2t8=dQ@mail.gmail.com>
In-Reply-To
<5188A36A.8000408@alum.mit.edu>
On Tue, May 7, 2013 at 1:47 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 27 quoted lines
> On 05/07/2013 06:47 AM, Felipe Contreras wrote:
>> On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>
>>> You conjectured earlier that nobody uses blob marks, and I provided a
>>> counterexample.  Then you proposed a workaround that would require
>>> changes to the cvs2git documentation, and I even explained how your
>>> proposed workaround is not as flexible as the status quo.
>>
>> cvs2git does *not* need blob marks, it does not need marks at all.
>>
>> The use-case that you mentioned has nothing to do with cvs2git, in
>> fact. I can be described as this:
>>
>> % ./generate-blobs > blobs
>> % git fast-import --export-marks=marks < blobs
>> % ./generate-commits > commits
>> % git fast-import --import-marks=marks < commits
>>
>> In this example 'generate-commits' has no notion of marks at all, and
>> 'git fast-import' doesn't need marks to process both blobs and
>> commits.
>
> The "generate-blobs" program generates a mark for each blob and
> remembers the marks in a database.  The "generate-commits" program reads
> the marks from the database and incorporates them in the definitions of
> the commits that it writes to its output.  So yes, the program pair
> *does* rely on marks for blobs being exported correctly.
Fine:

% ./generate-data > data % ./split-blobs data > blobs % ./split-commits data > commits

How exactly the files 'blobs' and 'commits' are generated is irrelevant, 'git fast-import' will need them *once*, and never again, in fact, doesn't even need to know they are two files. There's no need for marks.

> I've tired of this discussion.  I am quite sure that your change will
> not be accepted, so I see no need to participate further.  Please do not
> interpret my silence as agreement with your quarrelsome arguments.

How convenient. I ask the though questions, and you suddenly get tired of the discussion. So, let me answer for you:

* Which the *vastly* more common case? That blobs are needed, or that
they are not?
That they are not. To suggest otherwise would be ridiculous.

And of course this patch will not be accepted, because nobody is interested in improving things in the most easy and sensible way.

Yours and everybody else's argument is one and the same: status quo, which is of course, not an argument at all.

But it's pointless to try to convince you, because a) you are not interested in changing your mind b) you are not interested in seeking the most sensible solution c) you are only interested in doing what you are used to do, which is to not change anything, ever d) you know making this the default is only slightly risky, at best, and not only the world is not going to end, but most likely nobody would even notice, and the ones that would, are probably already participating in this conversation, but you don't even want to do something slightly risky, because it would show that others were right, and your concerns don't actually affect any real users at all.

But as I said, drop the patch. Who needs progress?
Cheers.
-- 
Felipe Contreras
Previous: Michael HaggertyNext: Junio C Hamano
Message 30 of 38 in “fast-export: speed improvements”
  1. 0/4 fast-export: speed improvementsFelipe Contreras, May 3, 2013
  2. 1/4 fast-{import,export}: use get_sha1_hex() directlyFelipe Contreras, May 3, 2013
  3. Junio C HamanoMay 3, 2013
  4. 2/4 fast-export: improve speed by skipping blobsFelipe Contreras, May 3, 2013
  5. Junio C HamanoMay 3, 2013
  6. 3/4 fast-export: don't parse all the commitsFelipe Contreras, May 3, 2013
  7. Junio C HamanoMay 3, 2013
  8. Felipe ContrerasMay 4, 2013
  9. Junio C HamanoMay 4, 2013
  10. 4/4 fast-import: only store commit objectsFelipe Contreras, May 3, 2013
  11. Thomas RastMay 3, 2013
  12. Felipe ContrerasMay 3, 2013
  13. Michael HaggertyMay 6, 2013
  14. Thomas RastMay 6, 2013
  15. Michael HaggertyMay 6, 2013
  16. Junio C HamanoMay 6, 2013
  17. Felipe ContrerasMay 6, 2013
  18. Felipe ContrerasMay 6, 2013
  19. Michael HaggertyMay 7, 2013
  20. Johannes SchindelinMay 7, 2013
  21. Felipe ContrerasMay 7, 2013
  22. Michael HaggertyMay 7, 2013
  23. Felipe ContrerasMay 7, 2013
  24. Felipe ContrerasMay 6, 2013
  25. Michael HaggertyMay 7, 2013
  26. Johannes SchindelinMay 7, 2013
  27. Felipe ContrerasMay 7, 2013
  28. Felipe ContrerasMay 7, 2013
  29. Michael HaggertyMay 7, 2013
  30. Felipe ContrerasMay 7, 2013
  31. Junio C HamanoMay 7, 2013
  32. Michael HaggertyMay 7, 2013
  33. Johannes SchindelinMay 6, 2013
  34. Felipe ContrerasMay 6, 2013
  35. Junio C HamanoMay 3, 2013
  36. Felipe ContrerasMay 3, 2013
  37. Junio C HamanoMay 3, 2013
  38. Felipe ContrerasMay 4, 2013

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.