Re: [PATCH v2 00/14] Sparse checkout

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

On 9/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
>  > On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
>
> > ...
>
> >>  >>  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