[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: [PATCH 01/14] Extend index to save more flags
From: Jakub Narebski <jnareb () gmail ! com>
Date: 2008-09-28 11:59:46
Message-ID: 200809281359.46858.jnareb () gmail ! com
[Download RAW message or body]
On Mon, 22 Sep 2008, Duy Nguyen wrote:
> On 09/22/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
>>On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>>> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>> +
>>>>> +#define CE_EXTENDED_FLAGS (0)
>>>>> +
>>>>> +/*
>>>>> + * Safeguard to avoid saving wrong flags:
>>>>> + * - CE_EXTENDED2 won't get saved until its semantic is known
>>>>> + * - Bits in 0x0000FFFF have been saved in ce_flags already
>>>>> + * - Bits in 0x003F0000 are currently in-memory flags
>>>>> + */
>>>>> +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
>>>>> +#error "CE_EXTENDED_FLAGS out of range"
>>>>> +#endif
>>>>
>>>>
>>>> I don't quite understand the above fragment (especially with the fact
>>>> that CE_EXTENDED_FLAGS is defined as (0))...
>>>
>>> Because this patch does not introduce any new on-disk flag yet so
>>> CE_EXTENDED_FLAGS remains 0. In the next patch, CE_EXTENDED_FLAGS will
>>> be updated to have CE_NO_CHECKOUT.
>>
>> Well, now I understand CE_EXTENDED_FLAGS being (0).
>>
>> What I still don't understand the pattern it is protected against.
>> As I understand it if CE_EXTENDED_FLAGS & 0x0000FFFF it is bad,
>> because ce_flags saved flags are not extended flags, and
>> CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags. But why
>> CE_EXTENDED_FLAGS & 0x80C00000 is bad, and why (if I understand it)
>> CE_EXTENDED_FLAGS & 0x00300000 is not bad.
>
> Wrong bit computation, should be "#if CE_EXTENDED_FLAGS & 0x803FFFFF".
> Thanks for pointing out.
So now there is:
Now CE_EXTENDED_FLAGS & 0x803FFFFF is bad because:
* CE_EXTENDED_FLAGS & 0x0000FFFF are saved flags (not extended)
* CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags
* CE_EXTENDED_FLAGS & 0x80000000 is 'extra flags' bit
(this is not mentioned in quoted comment; I'm not sure if
it needs to be or not)
Is that correct?
--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic