On Mon, May 6, 2013 at 11:39 PM, Johannes Schindelin
> On Tue, 7 May 2013, Michael Haggerty wrote:
>> On 05/06/2013 11:04 PM, Felipe Contreras wrote:
>> > On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty <mhag...@alum.mit.edu>
>> > wrote:
>> >> On 05/06/2013 12:32 PM, Thomas Rast wrote:
>> >> So the proposed change would break a documented use of cvs2git.
>> > It's documented as an alternative. How many people actually use this
>> > form over the other? Is there really any advantage? It's possibly that
>> > basically nobody is using this form, and there's no benefits.
>> You conjectured earlier that nobody uses blob marks, and I provided a
>> counterexample. Then you proposed a workaround that would require
>> changes to the cvs2git documentation, and I even explained how your
>> proposed workaround is not as flexible as the status quo. Do you want
>> to go through the same argument with every possible user of
>> It would be insanity to change the default behavior when a workaround on
>> the Git side (namely adding an option that tells git-fast-import *not*
>> to emit blob marks) would be quite straightforward to implement and have
>> little maintenance cost.
> I really wonder how many more counterexamples are required to settle this
One. I haven't seen one use-case that *requires* blob marks, I haven't
seen one tool that utilizes blob marks. And no, cvs2git doesn't use
marks at all.
> There is no good reason to artificially limit Git's capabilities here,
> especially when it has been demonstrated that supporting that capability
> is not only possible, but also outright easy.
Strawman. Nobody is arguing that there shouldn't be an option to
enable blob exporting, the argument is that there's no point in making
that the *default*.
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