On Mon, Feb 06, 2017 at 02:23:37PM -0600, Samuel Lijin wrote:
> >> There are some discussions in the past [1] [2] about this.
>
> I think you forgot to link to [2] :p
I think the [1] [2] there were recursive quotes from Duy's email. Those
footnotes were:
[1]
http://public-inbox.org/git/%3CCAEB
Nguyen wrote:
>>
>>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin wrote:
>>> > # Irrelevant but someone should take a look
>>> >
>>> > 693
>>>
>>> To save people some time (and since i looked at it anyway), this is
>>> abou
muel Lijin wrote:
>> > # Irrelevant but someone should take a look
>> >
>> > 693
>>
>> To save people some time (and since i looked at it anyway), this is
>> about whether "warning in tree xxx: contains zero-padded file modes:
>> from fsck
On Thu, Sep 05, 2013 at 01:13:40PM -0400, John Szakmeister wrote:
> > Yep. These were mostly caused by a bug in Grit that is long-fixed. But
> > the objects remain in many histories. It would have painful to rewrite
> > them back then, and it would be even more painful now.
>
> I guess there's s
On Thu, Sep 05, 2013 at 01:09:34PM -0400, Nicolas Pitre wrote:
> On Thu, 5 Sep 2013, Jeff King wrote:
>
> > There are basically two solutions:
> >
> > 1. Add a single-bit flag for "I am 0-padded in the real data". We
> > could probably even squeeze it into the same integer.
> >
> > 2.
On Thu, 5 Sep 2013, Jeff King wrote:
> On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > > There are basically two solutions:
> > >
> > > 1. Add a single-bit flag for "I am 0-padded in the real data". We
> > > could probably even squeeze it into the same integer.
On Thu, 5 Sep 2013, Jeff King wrote:
> There are basically two solutions:
>
> 1. Add a single-bit flag for "I am 0-padded in the real data". We
> could probably even squeeze it into the same integer.
>
> 2. Have a "classic" section of the pack that stores the raw object
> bytes. Fo
canter.git
>> Cloning into 'incanter'...
>> remote: Counting objects: 10457, done.
>> remote: Compressing objects: 100% (3018/3018), done.
>> error: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains
>> zero-padded file modes
>>
On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:
> > There are basically two solutions:
> >
> > 1. Add a single-bit flag for "I am 0-padded in the real data". We
> > could probably even squeeze it into the same integer.
> >
> > 2. Have a "classic" section of the pack
On 09/05/2013 11:36 AM, Jeff King wrote:
[...]
I haven't looked carefully at the pack v4 patches yet, but I suspect
that yes, it's still a problem. The premise of pack v4 is that we can do
better by not storing the raw git object bytes, but rather storing
specialized representations of the var
On Thu, Sep 5, 2013 at 10:36 PM, Jeff King wrote:
>> > This is going to screw up pack v4 (yes, someday I'll have the
>> > time to make it real).
>>
>> I don't know if this is still true, but given that patches are
>> being sent out about it, I thought it relevant.
>
> I haven't looked carefully at
ounting objects: 10457, done.
> remote: Compressing objects: 100% (3018/3018), done.
> error: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains
> zero-padded file modes
> fatal: Error in object
> fatal: index-pack failed
Yep. These were mostly caused by a bug i
or: object 4946e1ba09ba5655202a7a5d81ae106b08411061:contains
zero-padded file modes
fatal: Error in object
fatal: index-pack failed
At first, it surprised me that no one has seen the issue before,
but then I remembered I have transfer.fsckObjects=true in my
config. Turning it off, I was abl
13 matches
Mail list logo
