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

["Nguyen Thai Ngoc Duy" <pclouds@gmail.com>]

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?
 - consider only a and b in narrow area (new files not counted)
 - consider the whole directory in narrow area (new files counted)

This does not matter until we implement strict mode that only checkout
new files inside narrow area (the usage is similar to submodule).

>  > 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".
-- 
Duy