Re: [PATCH v2 00/14] Sparse checkout

"Nguyen Thai Ngoc Duy" [off-list ref] writes:

On 9/21/08, Jakub Narebski [off-list ref] wrote:
...

quoted

 >>  BTW I think that the same rules are used in gitattributes, aren't
 >>  they?
 >
 > They have different implementations. Though the rules may be the same.

Were you able to reuse either one?

No. .gitignore is tied to read_directory() while .gitattributes has
attributes attached. So I rolled out another one for index.

I am sorry, but that sounds like a rather lame excuse.  It certainly is
possible to introduce an "ignored" attribute and have .gitattributes file
specify that, instead of having an entry in .gitignore file, if you teach
read_directory() to pay attention to the attributes mechanism.  If we had
from day one that a more generic gitattributes mechanism, I would imagine
we wouldn't even had a separate .gitignore codepath but used the attribute
mechanism throughout the system.

Now I do not think we are ever going to deprecate gitignore and move
everybody to "ignored" attributes, because such a transition would not buy
the end users anything, but it technically is possible and would have been
the right thing to do, if we were building the system from scratch.  We
still could add it as an optional feature (i.e. if a path has the
attribute that says "ignored" or "not ignored", then that determines the
fate of the path, otherwise we look at gitignore).

I wouldn't be surprised if an alternative implementation of your code to
assign "sparseness" to each path internally used "to-be-checked-out"
attribute, and used that attribute to control how ls-files filters its
output.

A better excuse might have been that "I am not reading these patterns from
anywhere but command line", but that got me thinking further.

How would that --narrow-match that is not stored anywhere on the
filesystem but used only for filtering the output be any more useful than
a grep that filters ls-files output in practice?

I would imagine it would be much more useful if .git/info/attributes can
specify "checkout" attribute that is defined like this:

        `checkout`
        ^^^^^^^^^^

        This attribute controls if the path can be left not checked-out to the
        working tree.

        Unset::
                Unsetting the `checkout` marks the path not to be checked out.

        Unspecified::
                A path which does not have any `checkout` attribute specified is
                handled in no special way.

        Any value set to `checkout` is ignored, and git acts as if the
        attribute is left unspecified.

Then whenever a new path enters the index, you _could_ check with the
attribute mechanism to set the CE_NOCHECKOUT flag.  Just like an already
tracked path is not ignored even if it matches .gitignore pattern, a path
without CE_NOCHECKOUT that is in the index is checked out even if it has
checkout attribute Unset.

Hmm?