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:
>>> Michael Haggerty <mhag...@alum.mit.edu> writes:
>>>> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
>>>>> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast <tr...@inf.ethz.ch> wrote:
>>>>>> Felipe Contreras <felipe.contre...@gmail.com> writes:
>>>>>> How do we know that this doesn't break any users of fast-import? Your
>>>>>> comment isn't very reassuring:
>>>>>>> the vast majority of them will never be used again
>>>>>> So what's with the minority?
>>>>> Actually I don't think there's any minority. If the client program
>>>>> doesn't store blobs, the blob marks are not used anyway. So there's no
>>>> I haven't been following this conversation in detail, but your proposed
>>>> change sounds like something that would break cvs2git . Let me
>>>> explain what cvs2git does and why:
>>>> CVS stores all of the revisions of a single file in a single filename,v
>>>> file in rcsfile(5) format. The revisions are stored as deltas ordered
>>>> so that a single revision can be reconstructed from a single serial read
>>>> of the file.
>>>> cvs2git reads each of these files once, reconstructing *all* of the
>>>> revisions for a file in a single go. It then pours them into a
>>>> git-fast-import stream as blobs and sets a mark on each blob.
>>>> Only much later in the conversion does it have enough information to
>>>> reconstruct tree-wide commits. At that time it outputs git-fast-import
>>>> data (to a second file) defining the git commits and their ancestry.
>>>> The contents are defined by referring to the marks of blobs from the
>>>> first git-fast-import stream file.
>>>> This strategy speeds up the conversion *enormously*.
>>>> So if I understand correctly that you are proposing to stop allowing
>>>> marks on blob objects to be set and/or referred to later, then I object
>>> The proposed patch wants to stop writing marks (in --export-marks) for
>>> anything but commits. Does cvs2git depend on that? I.e., are you using
>>> two separate fast-import processes for the blob and tree/commit phases
>>> you describe above?
>> Yes, it can be handy to start loading the first "blobfile" in parallel
>> with the later stages of the conversion, before the second "dumpfile" is
>> ready. In that case the user needs to pass --export-marks to the first
>> fast-import process to export marks on blobs so that the marks can be
>> passed to the second fast-import via --import-marks.
> It can be used that way, but it doesn't have to be.
Please see my other email for an explanation of how the flexibility of
loading the two files separately can bring concrete benefits.
>> 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 git-fast-import?
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.
>> 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.
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