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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 7, 2013 at 1:47 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote:
> On 05/07/2013 06:47 AM, Felipe Contreras wrote:
>> On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]