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

[Junio C Hamano <gitster@pobox.com>]

Felipe Contreras <felipe.contreras@gmail.com> 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.  What about the others who do?

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

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?