On 9/21/08, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> > On 9/21/08, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
>
> > > 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`
> > > ^^^^^^^^^^
>
> [...]
>
>
> > > 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.
I just tried to see if it was feasible. Checking the source again, I
misunderstood gitattributes/gitingore's leading '/' notion (in a good
way). Leading '/' means './' and that would be fine for
.git{attributes,ignore}. In sparse patterns, leading '/' means
toplevel directory because you may want to checkout some more from a
subdirectory without moving up to toplevel directory. Now
.git{ignore,attributes} and sparse patterns are incompatible, gaah...
> Second, while unifying the "check the match" part of gitignore,
> gitattribute and sparse checkout would be IMVHO a good idea, I'm
It is surely good. Optimization like 68492fc (Speedup scanning for
excluded files.) could be applied to .gitattributes too. Now I know
why I was confused when reading the matching part of
.git{attributes,ignore}.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
