On Tue, May 7, 2013 at 1:47 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > On 05/07/2013 06:47 AM, Felipe Contreras wrote: >> On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> >>> 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. >> >> cvs2git does *not* need blob marks, it does not need marks at all. >> >> The use-case that you mentioned has nothing to do with cvs2git, in >> fact. I can be described as this: >> >> % ./generate-blobs > blobs >> % git fast-import --export-marks=marks < blobs >> % ./generate-commits > commits >> % git fast-import --import-marks=marks < commits >> >> In this example 'generate-commits' has no notion of marks at all, and >> 'git fast-import' doesn't need marks to process both blobs and >> commits. > > The "generate-blobs" program generates a mark for each blob and > remembers the marks in a database. The "generate-commits" program reads > the marks from the database and incorporates them in the definitions of > the commits that it writes to its output. So yes, the program pair > *does* rely on marks for blobs being exported correctly. Fine: % ./generate-data > data % ./split-blobs data > blobs % ./split-commits data > commits How exactly the files 'blobs' and 'commits' are generated is irrelevant, 'git fast-import' will need them *once*, and never again, in fact, doesn't even need to know they are two files. There's no need for marks. > I've tired of this discussion. I am quite sure that your change will > not be accepted, so I see no need to participate further. Please do not > interpret my silence as agreement with your quarrelsome arguments. How convenient. I ask the though questions, and you suddenly get tired of the discussion. So, let me answer for you: * Which the *vastly* more common case? That blobs are needed, or that they are not? That they are not. To suggest otherwise would be ridiculous. And of course this patch will not be accepted, because nobody is interested in improving things in the most easy and sensible way. Yours and everybody else's argument is one and the same: status quo, which is of course, not an argument at all. But it's pointless to try to convince you, because a) you are not interested in changing your mind b) you are not interested in seeking the most sensible solution c) you are only interested in doing what you are used to do, which is to not change anything, ever d) you know making this the default is only slightly risky, at best, and not only the world is not going to end, but most likely nobody would even notice, and the ones that would, are probably already participating in this conversation, but you don't even want to do something slightly risky, because it would show that others were right, and your concerns don't actually affect any real users at all. But as I said, drop the patch. Who needs progress? Cheers. -- 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