On Wed, May 25, 2016 at 10:49:07PM +, Eric Wong wrote:
> > Thanks for the analysis. I think this is definitely the problem. After
> > fast-import finalizes a packfile (either at the end of the program or
> > due to a checkpoint), it never discards its internal mapping of objects
> > to pack
Jeff King wrote:
> On Tue, May 17, 2016 at 10:07:16AM +0200, Lars Schneider wrote:
>
> > I think that is pretty much the problem. Here is what is happening:
> >
> > 1. git-p4 imports all changelists for the "main" branch
> >
> > 2. git-p4 starts to import a second branch and
> On 19 May 2016, at 19:03, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> From my point of view little packs are no problem. I run fast-import on
>> a dedicated migration machine. After fast-import completion I run repack [1]
>> before I
Lars Schneider writes:
> From my point of view little packs are no problem. I run fast-import on
> a dedicated migration machine. After fast-import completion I run repack [1]
> before I upload the repo to its final location.
How do you determine that many little
On 17 May 2016, at 14:13, Jeff King wrote:
> On Tue, May 17, 2016 at 10:07:16AM +0200, Lars Schneider wrote:
>
>> I think that is pretty much the problem. Here is what is happening:
>>
>> 1. git-p4 imports all changelists for the "main" branch
>>
>> 2. git-p4 starts to
On Tue, May 17, 2016 at 10:07:16AM +0200, Lars Schneider wrote:
> I think that is pretty much the problem. Here is what is happening:
>
> 1. git-p4 imports all changelists for the "main" branch
>
> 2. git-p4 starts to import a second branch and creates a fast-import
> "progress
Lars Schneider wrote:
> I am no expert in "fast-import". Does anyone have a few hints how to
> proceed?
I don't know fast-import or the C internals of git well at all,
either. But capturing the exact input to fast-import (using
tee) would be useful for non-p4 users to
On 14 May 2016 at 19:15, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>>>
>>> Are you saying that "git p4" itself breaks unless fast-import always
>>> writes a new (tiny)
> On 14 May 2016, at 20:15, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>>>
>>> Are you saying that "git p4" itself breaks unless fast-import always
>>> writes a new
Lars Schneider writes:
>> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>>
>> Are you saying that "git p4" itself breaks unless fast-import always
>> writes a new (tiny) packfile? That sounds quite broken, and setting
>> unpacklimit to 0 does not
> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>
> Eric Wong writes:
>
>> Lars Schneider wrote:
>>> Hi,
>>>
>>> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
>>> d9545c7
>>> "fast-import: implement
Eric Wong writes:
> Lars Schneider wrote:
>> Hi,
>>
>> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
>> d9545c7
>> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>>
>> Did anyone look into that
Lars Schneider wrote:
> Hi,
>
> t9801 and t9803 seem to be broken on next. A quick bisect indicates that
> d9545c7
> "fast-import: implement unpack limit" might be the reason. (@gmane/292562).
>
> Did anyone look into that already?
Just took a look (no p4, so
Hi,
t9801 and t9803 seem to be broken on next. A quick bisect indicates that
d9545c7
"fast-import: implement unpack limit" might be the reason. (@gmane/292562).
Did anyone look into that already?
Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
14 matches
Mail list logo