On Mon, May 6, 2013 at 8:59 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>> * 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
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
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
Sometimes it makes sense to make a new feature opt-in, sometimes it
doesn't, there are no absolutes, there should be no dogmas.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html