Felipe Contreras <felipe.contre...@gmail.com> writes: >> The story is different on the fast-import side, where we do say we >> dump the full table and a later run can depend on these marks. > > Yes, and gaining nothing but increased disk-space.
I thought that the "gaining nothing" has already been refuted by the discussion several hours ago... cf. http://thread.gmane.org/gmane.comp.version-control.git/223275/focus=223440 Puzzled... >> By discarding marks on blobs, we may be robbing some optimization >> possibilities, and by discarding marks on tags, we may be robbing >> some features, from users of fast-export; we might want to add an >> option "--use-object-marks={blob,commit,tag}" or something to both >> fast-export and fast-import, so that the former can optionally write >> marks for non-commits out, and the latter can omit non commit marks >> if the user do not need them. But that is a separate issue. > > How? * if we teach fast-import to optionally not write marks for blobs and trees out, your remote-bzr can take advantage of it, because it does not reuse marks for non-commits in later runs, right? Existing users like cvs2git that do not ask to skip marks for non-commits will not be hurt and keep referring to blobs an earlier run wrote out. * if we teach fast-export to optionally write marks for blobs and trees out, the users of fast-export could reuse marks for blobs and trees in later runs (perhaps they can drive fast-export from the output of "git log --raw", noticing blob object names they already saw). Existing users that do not ask for such a feature will not be hurt. -- 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
