On 05/07/2013 09:12 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> 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 sing
Michael Haggerty writes:
> 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
On Tue, May 7, 2013 at 1:47 AM, Michael Haggerty wrote:
> On 05/07/2013 06:47 AM, Felipe Contreras wrote:
>> On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty
>> wrote:
>>
>>> You conjectured earlier that nobody uses blob marks, and I provided a
>>> counterexample. Then you proposed a workaroun
On 05/07/2013 06:47 AM, Felipe Contreras wrote:
> On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty
> 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, a
On Mon, May 6, 2013 at 11:39 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Tue, 7 May 2013, Michael Haggerty wrote:
>
>> On 05/06/2013 11:04 PM, Felipe Contreras wrote:
>> > On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty
>> > wrote:
>> >> On 05/06/2013 12:32 PM, Thomas Rast wrote:
>
>> >> So the
On Mon, May 6, 2013 at 10:27 PM, Michael Haggerty 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
Hi,
On Tue, 7 May 2013, Michael Haggerty wrote:
> On 05/06/2013 11:04 PM, Felipe Contreras wrote:
> > On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty
> > wrote:
> >> On 05/06/2013 12:32 PM, Thomas Rast wrote:
> >> So the proposed change would break a documented use of cvs2git.
> >
> > It's d
On Mon, May 6, 2013 at 9:58 PM, Michael Haggerty wrote:
> On 05/06/2013 11:19 PM, Felipe Contreras wrote:
>> On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote:
>>> Michael Haggerty writes:
>>>
Yes, it can be handy to start loading the first "blobfile" in parallel
with the later sta
On Mon, May 6, 2013 at 11:32 PM, Johannes Schindelin
wrote:
> Hi Michael,
>
> On Tue, 7 May 2013, Michael Haggerty wrote:
>
>> I knew about the "type" command but I was under the impression that it
>> is intended for text files and can corrupt binary files. Are you sure
>> that using "type" as yo
Hi Michael,
On Tue, 7 May 2013, Michael Haggerty wrote:
> I knew about the "type" command but I was under the impression that it
> is intended for text files and can corrupt binary files. Are you sure
> that using "type" as you suggest is binary-clean?
"type" is not binary-clean. At least on so
On 05/06/2013 11:04 PM, Felipe Contreras wrote:
> On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty wrote:
>> On 05/06/2013 12:32 PM, Thomas Rast wrote:
>>> Michael Haggerty writes:
>>>
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
On 05/06/2013 11:36 PM, Felipe Contreras wrote:
> This would simplify the documentation, and obliterate the need to use
> mark files at all:
As explained in my other email, this documentation change does not
remove all of the reasons that users might want to use mark files. I
would still like to
On 05/06/2013 11:19 PM, Felipe Contreras wrote:
> On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> 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
On Mon, May 6, 2013 at 4:19 PM, Felipe Contreras
wrote:
> On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> 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
On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> 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 t
On Mon, May 6, 2013 at 7:20 AM, Johannes Schindelin
wrote:
> Hi Thomas,
>
> On Mon, 6 May 2013, Thomas Rast wrote:
>
>> The proposed patch wants to stop writing marks (in --export-marks) for
>> anything but commits.
>
> Then it should not go in.
If that rationale was valid, no change in behavior
On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty wrote:
> On 05/06/2013 12:32 PM, Thomas Rast wrote:
>> Michael Haggerty writes:
>>
>>> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
> Felipe Contreras writes:
> How do we kn
Michael Haggerty writes:
> 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
Hi Thomas,
On Mon, 6 May 2013, Thomas Rast wrote:
> The proposed patch wants to stop writing marks (in --export-marks) for
> anything but commits.
Then it should not go in.
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.k
On 05/06/2013 12:32 PM, Thomas Rast wrote:
> Michael Haggerty writes:
>
>> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
>>> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
Felipe Contreras writes:
>>>
How do we know that this doesn't break any users of fast-import? Your
c
Michael Haggerty writes:
> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
>> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
>>> Felipe Contreras writes:
>>
>>> How do we know that this doesn't break any users of fast-import? Your
>>> comment isn't very reassuring:
>>>
the vast majo
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
>> Felipe Contreras 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 agai
On Fri, May 3, 2013 at 6:45 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> A safe and sane approach may be to teach these an option to tell
>>> them to omit non-commits or to emit all kinds, and make remote-bzr
>>> use that to exclude non-commits.
>>
>> This has nothing to do with rem
Felipe Contreras writes:
>> A safe and sane approach may be to teach these an option to tell
>> them to omit non-commits or to emit all kinds, and make remote-bzr
>> use that to exclude non-commits.
>
> This has nothing to do with remote-bzr, or any remote helper. These
> objects are not useful,
On Fri, May 3, 2013 at 5:08 PM, Junio C Hamano wrote:
> Thomas Rast writes:
>
>> IIUC, you are unconditionally storing only marks to commit objects.
>>
>> Are you allowed to do that at this point? I notice that
>> git-fast-export(1) says
>>
>>--export-marks=
>>Dumps the internal mark
Thomas Rast writes:
> IIUC, you are unconditionally storing only marks to commit objects.
>
> Are you allowed to do that at this point? I notice that
> git-fast-export(1) says
>
>--export-marks=
>Dumps the internal marks table to when complete. Marks are
>written one per lin
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
> Felipe Contreras 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 thin
Felipe Contreras writes:
> There's no point in storing blob, they would increase the time of
> loading the marks, and the vast majority of them will never be used
> again.
>
> This also makes fast-export and fast-import marks compatible.
[...]
> - if (m->data.marked[k])
> +
28 matches
Mail list logo
