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