Re: [PATCH v2 00/14] Sparse checkout
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Sep 21, 2008, 10:11 UTC
- Message-ID
- <fcaeb9bf0809210311x7e9337fbmd978e95aa7998525@mail.gmail.com>
- In-Reply-To
- <7vzlm21n83.fsf@gitster.siamese.dyndns.org>
On 9/21/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 40 quoted lines
> "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.
Show 26 quoted lines
> 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