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


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

Reply via email to