Nguyễn Thái Ngọc Duy [off-list ref] writes:
The implementation with insights from Junio turns out smaller and better
(and I was thinking about applying it for huge maildir).
I think I can agree with the general direction this is taking, except that
we would need to think about the transition plans. Note that I haven't
really read through the full series yet.
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.
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.
On 8/16/08, Junio C Hamano [off-list ref] wrote:
Nguyen Thai Ngoc Duy [off-list ref] 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