Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

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

 



On Mon, May 6, 2013 at 8:59 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>
>>>> How?
>>>
>>>  * if we teach fast-import to optionally not write marks for blobs
>>>    and trees out, your remote-bzr can take advantage of it,
>>
>> I already said remote-bzr is irrelevant. *Everybody* benefits.
>
> Everybody who does _not_ need to look at marks for non-commits from
> previous run does.

IOW; everyone.

> What about the others who do?

Like who?

> Surely, some lucky ones may get the benefit of a new optimization
> for free if you turn it on uncondtionally without an escape hatch,
> but that goes against our goal of not to knowingly introduce any
> regression.

That's different. One thing is to turn it on unconditionally, and
another thing is to turn it on by *default*.

> Michael's cvs2git might have a way to work the breakage
> around (I will let him comment on your suggested workaround), but as
> long as he has been coding it using the documented feature, why
> should he even change anything for no gain at all in the first
> place?  Even if you have a workaround, that does not change the fact
> that a removal of a feature that somebody has been depending on is a
> regression.

Who is depending on it? Michael didn't say that he used that feature,
merely that it was documented in cvs2git, because Windows doesn't have
'cat'. He claimed that other people *might* be using that "feature",
but we don't *know*.

Is a couple of commands somebody wrote in some documentation which can
be easily fixed, reason enough to punish everyone else?

> What's so difficult to understand that by default the responsibility
> of making sure an optimization applies safely to a program that uses
> a new optmization lies on that program, in other words, a new
> feature is by default an opt-in?

Is that written in some git bible descended from some god that I
missed? If not, everything are guidelines, and guidelines are there
for a reason, and those reasons can be challenged, and so can the
guidelines.

Sometimes it makes sense to make a new feature opt-in, sometimes it
doesn't, there are no absolutes, there should be no dogmas.

-- 
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]