On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
On 9/21/08, Junio C Hamano [off-list ref] wrote:
quoted
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.
quoted
I would imagine it would be much more useful if .git/info/attributes can
specify "checkout" attribute that is defined like this:
`checkout`
^^^^^^^^^^
[...]
quoted
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.
First, I think that this was Junio asking for discussion more than
for changing the design.
Second, while unifying the "check the match" part of gitignore,
gitattribute and sparse checkout would be IMVHO a good idea, I'm
not sure if trying to use/reuse attr.c literally would be a good
idea, at least not without larger surgery. AFAIK, IIUC gitattributes
have some limitations, one of which that they are read from working
area (and there is no API for reading from tree); although this could
be enough for `checkout' attribute, which is not that different in
work from `smudge' attribute, or `crlf` attribute.
--
Jakub Narebski
Poland