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

> Junio C Hamano <gitster@pobox.com> writes:
>
>  > "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > ...
>
> >> 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:
>
> > ...
>
> > you can record list of pathspecs (with positive and negative) to implement
>  > that semantics, no?
>
> By the way, I was just mentioning the index extension area as a means to
>  store the rules if _you wanted to_.  I do not insist you to actually store
>  the rules, and in fact, I do not know if it is even a good idea to do so.

>  > 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.
>
>
> It might make sense to do this first as a futureproof, if we really want
>  to go this route.  We can ensure that an index that does use the new flag
>  bits won't be misinterpreted by older git.