Re: [RFC PATCH 0/9] Narrow/Sparse checkout round 3: "easy mode"

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2008, 05:50 UTC
Message-ID: <7vbpzs9om7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <fcaeb9bf0808162212y756465a5ib7ce3a8849765033@mail.gmail.com>

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

Show 20 quoted lines

> On 8/16/08, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>  > Another difference from the last round is "narrow rules" will not be preserved
>>  > when switching branches. When you switch branch with no option, you will get
>>  > full checkout. You may want to use --path|--add-path|--remove-path when
>>  > switching branches to have narrow checkout again.
>>
>>
>> You could save the "narrow rules" in the extension section of the index.
>>  If the final form of this series needs to use a separate CE_NO_CHECKOUT
>>  bit (which would make the resulting index incompatible with the current
>>  git), the narrow rules section can be marked as "your git must understand
>>  this" class of extension to make sure that people do not mistakenly access
>>  an index written by this new version of git with the current or older git.
>
> The problem is "narrow rules" may change over time in a way that git
> may handle it wrong. Assume that you have a directory with two files:
> a and b. You first narrow checkout a (which would save the rule
> "checkout a"). Then you do "git checkout b". When you update HEAD,
> what should happen?

I'd expect that this sequence:

	git checkout --set-no-checkout arch include
        git checkout arch/x86 include/asm-x86

to set up narrowing rules to (1) exclude everything in arch/ and include/ area by default, but (2) allow checking out everything in arch/x86/ and include/asm-x86/ that currently exist _and_ will exist in different commits when we switch to.

On the other hand, if I did this after the above two-command sequence:

	git checkout include/Kbuild

then I'd expect only that file to be added to the checkout set. I think you can record list of pathspecs (with positive and negative) to implement that semantics, no?

Show 10 quoted lines

>>  > Now back to technical POV. I did not reuse CE_VALID (assume unchanged) bit
>>  > because it has been used for core.ignorestat.
>>
>> I am not sure what's the relation between these two.
>
> Because the usage is different? When you "git update-index foo" with
> core.ignorestat=1, it will mark it CE_VALID. And if the same bit is
> used for narrow checkout, the file is considered not existing in
> workdir. I'd expect foo is still in my narrow area after "git
> update-index foo".

Ok.  We would need to use an extra bit for this.

The bit 0x4000 is the last one available, so we would want to use it as "this index entry uses more bits than the traditional format" bit, and define a backward incompatible on-disk index entry format to actually record CE_NO_CHECKOUT and other flags we will invent in the future.

Perhaps ondisk_cache_entry structure will have an extra "unsigned int flags2" after "flags" when that bit is on, and we can have 31 more bits in flags2, with the highest bit of flags2 signalling the presense of flags3 word in the future, or something like that.

By the way, "uint" and "ushort" in struct ondisk_cache_entry are 4-byte and 2-byte network byte order integers; should we write them as uint32_t and uint16_t instead in the longer run?