On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty <mhag...@alum.mit.edu> 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. > Do you want > to go through the same argument with every possible user of git-fast-import? I don't care about possible users, I care about *real* users. > 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. And nobody would benefit from that. >>> Making the export of blob marks optional would of course be OK, as long >>> as the default is to export them. >> >> Nobody benefits from leaving the default as it is. > > Sure they do. Any tool that *knows* that it doesn't need blob marks can > pass the new option and benefit. Other tools benefit from not being > broken by your change. Which the *vastly* more common case? That blobs are needed, or that they are not? -- Felipe Contreras -- 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
