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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 7, 2013, 04:47 UTC
Message-ID: <CAMP44s3vGKv-Z6sx0sjAPH7_U1+AiJjFHjKz8ke+EUqW-u2Y=A@mail.gmail.com>
In-Reply-To: <518874A5.5050002@alum.mit.edu>

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.

> Do you want
> to go through the same argument with every possible user of git-fast-import?

I don't care about possible users, I care about *real* users.

> It would be insanity to change the default behavior when a workaround on
> the Git side (namely adding an option that tells git-fast-import *not*
> to emit blob marks) would be quite straightforward to implement and have
> little maintenance cost.

And nobody would benefit from that.

Show 8 quoted lines

>>> Making the export of blob marks optional would of course be OK, as long
>>> as the default is to export them.
>>
>> Nobody benefits from leaving the default as it is.
>
> Sure they do.  Any tool that *knows* that it doesn't need blob marks can
> pass the new option and benefit.  Other tools benefit from not being
> broken by your change.

Which the *vastly* more common case? That blobs are needed, or that they are not?

-- 
Felipe Contreras