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