Re: [PATCH v2 00/14] Sparse checkout

On 9/21/08, Junio C Hamano [off-list ref] wrote:

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

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

quoted

...

quoted

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.

That "from command line" piece makes a bit of difference. For example
patterns separated by colons and backslash escape, but that does not
stop it from reusing attr.c.

 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?

Well, it works exactly like 'grep' internally.

 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?

Well I think people would want to save no-checkout rules eventually.
But I don't know how they want to use it. Will the saved rules be hard
restriction, that no files can be checked out outside defined areas?
Will it be to save a couple of keystrokes,   that is, instead of
typing "--reset-sparse=blah" all the time, now just "--reset-sparse"
and default rules will be applied? Your suggestion would be the third,
applying on new files only.

Anyway I will try to extend attr.c a bit to take input from command
line, then move "sparse patterns" over to use attr.c.
-- 
Duy