Re: [RFC] extending git-ls-files --exclude.
On 7/29/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > While I would in principle prefer to offer more freedom to shoot > yourselves in the foot ;-), the pragmatic side of me says too > much flexibility is just asking for trouble with not much > additional gain. For an example of just how far you can go down the road to mind numbing complexity try reading the rsync manpage about how to exclude files. -Wayne - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Petr Baudis wrote: Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... Hi, A Large Angry SCM wrote: So you're arguing for "last match wins" versus "first match wins". I, personally, find the former more natural and easier to debug by hand. You know, up until five minutes ago, I thought so too. So is the Large Angry SCM agreeing with me or not? I wrote long reply to his mail, then reread what he wrote again, and decided that he is _agreeing_ with me and you that "last match wins" is better. :-) *Oops!* Yes, it looks that way doesn't it. But I had accidentally [*1*] typed "former" where I wanted "later". Either way works as long as it's well documented/understood. [*1*] Either too much or too little caffeine at the time I suspect. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > In the meantime, the current one is clearly broken as you > pointed out, so let's replace it with the updated "generic rule > with the following exceptions" one. That's fine by me. I would only like to ask the Porcelain authors to keep their git-ls-files exclude parameters order matching the internal ordering so that when we indeed change it in the future to follow the commandline order, the Porcelains won't break. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Petr Baudis <[EMAIL PROTECTED]> writes: > Hmm. What about just excluding the files according to the order of > parameters on the command line? > > Here, the question is whether the GIT Core tools should provide full > flexibility and friendness to custom use, or rather serve as tighter > unifying layer for the porcelains, enforcing certain conventions. While I would in principle prefer to offer more freedom to shoot yourselves in the foot ;-), the pragmatic side of me says too much flexibility is just asking for trouble with not much additional gain. For example, your "generic first, and then list exceptions" argument convinced me to shelve the "first match wins" rule, but I _could_ have added an extra option to allow other Porcelain writers who want to have "most number of match wins" rule while at it. I didn't. Let's wait and see if somebody else comes up with a different use scenario that would be useful in real life. In the meantime, the current one is clearly broken as you pointed out, so let's replace it with the updated "generic rule with the following exceptions" one. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Hi,
Petr Baudis:
> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
> where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> > Hi, A Large Angry SCM wrote:
> >
> > > So you're arguing for "last match wins" versus "first match wins". I,
> > > personally, find the former more natural and easier to debug by hand.
> >
> > You know, up until five minutes ago, I thought so too.
>
> So is the Large Angry SCM agreeing with me or not? I wrote long reply to
> his mail, then reread what he wrote again, and decided that he is
> _agreeing_ with me and you that "last match wins" is better. :-)
>
Bah, I misparsed his sentence (I read "former" as "first wins"), otherwise
my reply would have been worded slightly differently.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"All these black people are screwing up my democracy." - Ian Smith
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > * When checking a file to see if it is excluded, we first look >at "exclude-from patterns" list, then "per directory >patterns" list, and then "command line patterns list", in >that order. The last match wins [*1*]. Hmm. What about just excluding the files according to the order of parameters on the command line? Here, the question is whether the GIT Core tools should provide full flexibility and friendness to custom use, or rather serve as tighter unifying layer for the porcelains, enforcing certain conventions. That's up to you to decide, obviously, but perhaps someone will want to use the exclude mechanisms for something else than the "classic" other files ignoring stuff, and generally more flexibility might be better. So I'd argue for codifying those conventions at the level of the porcelain users and not enforcing them in git-ls-files itself. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... > Hi, A Large Angry SCM wrote: > > > So you're arguing for "last match wins" versus "first match wins". I, > > personally, find the former more natural and easier to debug by hand. > > You know, up until five minutes ago, I thought so too. So is the Large Angry SCM agreeing with me or not? I wrote long reply to his mail, then reread what he wrote again, and decided that he is _agreeing_ with me and you that "last match wins" is better. :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Petr Baudis <[EMAIL PROTECTED]> writes: > You generally don't say "I never want this ignored, but I want > the rest of that ignored", but "I want that ignored, except > this". OK. > But more importantly, > > .gitignore: *.txt > Documentation/.gitignore: !*.txt > > will not work, which was the whole _point_ of the exclusion. I agree that this is a bigger issue. My updated proposal is as follows: * We collect --exclude patterns in "command line patterns" list, in the same order as given on the command line. * We collect patterns read from the files specified with --exclude-from in "exclude-from patterns" list, in the same order as given on the command line and the same order patterns appear in the file. * While we descend the directories, files named by EPD flag, if found, are read from top to bottom and concatenated into the "per directory patterns" list. When leaving the directory, the patterns read from that directory's EPD file are popped off. * When checking a file to see if it is excluded, we first look at "exclude-from patterns" list, then "per directory patterns" list, and then "command line patterns list", in that order. The last match wins [*1*]. An example: You have three files in your git source tree and your $HOME: git/.gitignore lists patterns A and B git/Documentation/.gitignorelists patterns C and D git/.git/info/ignorelists patterns E and F $HOME/.gitrc/ignore lists patterns G and H You say: git-ls-files --others \ --exclude=I --exclude=J \ --exclude-from=.git/info/ignore \ --exclude-from=~/.gitrc/ignore \ --exclude-per-directory=.gitignore \ While in git/ directory itself, the following patterns are checked and the last match wins: E F G H A B I J When we descend into git/Documentation, the list of patterns used becomes the following, still the last match wins: E F G H A B C D I J The reason --exclude-from comes first (i.e. having the least say in the outcome) and --exclude comes last (i.e. having the most say) is because the former is to give the overall fallback default, and the latter is the ultimate end user preference. Does this sound reasonable? [Footnote] *1* In real implementation, I would probably scan in reverse from the end and stop at the first match, but that is an implementation detail. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Hi, A Large Angry SCM wrote:
> So you're arguing for "last match wins" versus "first match wins". I,
> personally, find the former more natural and easier to debug by hand.
You know, up until five minutes ago, I thought so too.
However ... as a human being, I liik for meaning, not for processing
instructions. Thus, reading the list top-down, this
> *.html
> !f*.html
> fo*.html
makes perfect sense to me. ("Throw away the HTML files. Well, except for
those that start with 'f'. Well, *except* for foobar.html or whatever.")
The other way round, however, the sequence
> fo*.html
> !f*.html
> *.html
is not immediately understandable in one pass, as the second line makes no
sense whatsoever without the third one. ("Throw away foobar.html. Umm,
we're keeping everything anyway, so why ... oh, HTML files are junked, OK,
so ... now ... umm, what did I want to find out in the first place?")
It gets even more confusing when you're lazy and omit the .html suffix in
the second line.
YMMV, and all that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
(It is an old Debian tradition to leave at least twice a year ...)
-- Sven Rudolph
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Petr Baudis wrote: I think this is wrong, and my brief experiments confirm that. I think that the actually useful semantics of exclusion would be for _subsequent_ exclusions, not preliminary ones. You generally don't say "I never want this ignored, but I want the rest of that ignored", but "I want that ignored, except this". This also gives you more flexibility: *.html !f*.html fo*.html would ignore *.html and fo*.html, but not any other f*.html filenames. But more importantly, .gitignore: *.txt Documentation/.gitignore: !*.txt will not work, which was the whole _point_ of the exclusion. So you're arguing for "last match wins" versus "first match wins". I, personally, find the former more natural and easier to debug by hand. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > On Mon, 25 Jul 2005, Junio C Hamano wrote: > >> > >> I personally do not have preference either way, but am slightly > >> biased towards the "cumulative" behaviour the patch attempts to > >> implement, which was what Pasky said he wanted to have. > > > > I think that makes sense. > > > > Imagine, for example, that you have separate subdirectory structures for > > Documentation and for source - maybe you'd put the "*.o" rule in the > > source directory, and a "*.1" rule in the Docs subdirectory. > > I imagined it, but it appears to me that this is a bad example. > My understanding of what Catalin and the proposed patch > disagrees is whether the patterns in .gitignore at the top level > should govern files under ppc/ and mozilla-sha1/ subdirectories; > Catalin thinks they should not. They should. If you don't want them take effect in most of the directories, you would add them as ./pattern in the parent directory, while if you want them to take effect in most of the directories, you would exclude them in the ones you don't want the pattern to take effect in (if you accept my proposal for ! semantics change). > What I meant by "cumulative" (now I realize I might have > misunderstood what Pasky wanted to mean by that word, though) > was not just .gitignore in subdirectory being added, but the > effect of patterns being added so far, either from the command > line or by parent directories, last while in the deeper > directories. Yes, that's what I meant. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Hello, after skimming through it, I think I completely like what you have shown here. I'm only concerned about this: Dear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > $ cat Documentation/.gitignore > # ignore generated html files, > # except foo.html which is maintained by hand > !foo.html > *.html I think this is wrong, and my brief experiments confirm that. I think that the actually useful semantics of exclusion would be for _subsequent_ exclusions, not preliminary ones. You generally don't say "I never want this ignored, but I want the rest of that ignored", but "I want that ignored, except this". This also gives you more flexibility: *.html !f*.html fo*.html would ignore *.html and fo*.html, but not any other f*.html filenames. But more importantly, .gitignore: *.txt Documentation/.gitignore: !*.txt will not work, which was the whole _point_ of the exclusion. Could we please have this semantics changed for those reasons? Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Marco Costalba <[EMAIL PROTECTED]> writes: > This cumulative effect brakes local scoping of .gitignore files in > corresponding subdirectory. > > As example in a directory A we can have a .gitignore file with > > !foo.html > *.html > > because we want to special case 'that' foo.html in 'that' > directory. I guess that !foo.html I wrote was a bad example of special case not being specific enough. Saying "!/foo.html" should work [*1*], so I think "cumulative effect _breaks_" is a bit too strong a word. Having said that,... > This can be powerful and flexible but also prone to errors. While I also suspect it _might_ be prone to user errors, at least to some classes of users, Catalin (and Peter as well I suspect, although I may be mistaken by what he originally meant by "cumulative") seems to think it is OK. As a developer of another Porcelain (qgit), your input is as valuable as others, so... BTW, I am CC'ing git list because I saw you forwarded your entire message to the list as a quoted message form. Please do not do that. I cannot distinguish a message like that with a message with nothing but quote and no original contents, which I normally discard without even reading. [Footnote] *1* I just tried, and it seems to work. $ rm -f .gitignore ppc/.gitignore $ (echo '!/foo.bar'; echo '*.bar') >.gitignore $ for i in foo.bar baz.bar; do date >$i; date >ppc/$i; done $ git-ls-files --others --exclude-per-directory=.gitignore | grep '\.bar' foo.bar $ rm -f .gitignore ppc/.gitignore - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Re: [RFC] extending git-ls-files --exclude.
--- Marco Costalba <[EMAIL PROTECTED]> wrote: > Date: Mon, 25 Jul 2005 14:34:56 -0700 (PDT) > From: Marco Costalba <[EMAIL PROTECTED]> > Subject: Re: [RFC] extending git-ls-files --exclude. > To: Junio C Hamano <[EMAIL PROTECTED]> > CC: Linus Torvalds <[EMAIL PROTECTED]>, > Catalin Marinas <[EMAIL PROTECTED]>, Petr Baudis <[EMAIL PROTECTED]> > > Junio C Hamano wrote: > > >Linus Torvalds <[EMAIL PROTECTED]> writes: > > > >>On Mon, 25 Jul 2005, Junio C Hamano wrote: > >> > >I imagined it, but it appears to me that this is a bad example. > >My understanding of what Catalin and the proposed patch > >disagrees is whether the patterns in .gitignore at the top level > >should govern files under ppc/ and mozilla-sha1/ subdirectories; > >Catalin thinks they should not. > > > >What I meant by "cumulative" (now I realize I might have > >misunderstood what Pasky wanted to mean by that word, though) > >was not just .gitignore in subdirectory being added, but the > >effect of patterns being added so far, either from the command > >line or by parent directories, last while in the deeper > >directories. > > > > This cumulative effect brakes local scoping of .gitignore files in > corresponding subdirectory. > > As example in a directory A we can have a .gitignore file with > > !foo.html > *.html > > because we want to special case 'that' foo.html > in 'that' directory. > > If for any reason in any of part of subdirectories tree > with base A there is (or there will be in the future) another > foo.html this will be automatically special cased because > of cumulative adding of patterns. > > This can be powerful and flexible but also prone to errors. > > Peraphs can be better to use just one file with global scope > (as example .git/exclude) and all the others .gitignore files > with scope local to their directory. > > > Marco > > > > > > > > > > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote: > Catalin Marinas <[EMAIL PROTECTED]> writes: > >> An exclude pattern is of the following format: > > [...] > > > > That's fine. Actually, the Porcelain would care much about it since it > > gets the information already filtered by git. > > Your saying "fine" is a relief. This change aims at helping > Porcelain people by making it less likely for Porcelain to need > its own filtering. As you say, if ls-files filters more than > the Porcelain wants, that's a bigger problem. I don't plan to add any additional filtering in StGIT. What I meant above was that Porcelain would not care much about the patterns. The user should cope with what git provides, nothing more. With these git patches, I think there are enough features for filtering. > > Wouldn't it be clearer to have the general rules first (*.html), > > overridden by the more specific ones (!foo.html)? Just my opinion, I > > don't know what others think. > > I do not know, either, but I do know it is consistent with the > "first match determines fate" rule and cleaner to implement. I also don't have a strong preference for this and the "first match" rule clarifies it (otherwise, you could have pushed them on a list in reverse order). -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > Imagine, for example, that you have separate subdirectory structures for > > Documentation and for source - maybe you'd put the "*.o" rule in the > > source directory, and a "*.1" rule in the Docs subdirectory. > > I imagined it, but it appears to me that this is a bad example. > My understanding of what Catalin and the proposed patch > disagrees is whether the patterns in .gitignore at the top level > should govern files under ppc/ and mozilla-sha1/ subdirectories; > Catalin thinks they should not. I really don't have a strong preference for this. Linus' example makes sense as well. It's up to you how you implement its behaviour, Porcelains shouldn't be affected by this. Since I'm the only one with this idea, you can forget about it (I don't mind :-) ). If others express a preference for this, you could implement a 'cut' label (similar to Prolog's cut operator) which clears the pattern stack before diving into subdirectories. Anyway, I don't think it's worse the hassle since it might never be used. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Mon, 25 Jul 2005, Junio C Hamano wrote: >> >> I personally do not have preference either way, but am slightly >> biased towards the "cumulative" behaviour the patch attempts to >> implement, which was what Pasky said he wanted to have. > > I think that makes sense. > > Imagine, for example, that you have separate subdirectory structures for > Documentation and for source - maybe you'd put the "*.o" rule in the > source directory, and a "*.1" rule in the Docs subdirectory. I imagined it, but it appears to me that this is a bad example. My understanding of what Catalin and the proposed patch disagrees is whether the patterns in .gitignore at the top level should govern files under ppc/ and mozilla-sha1/ subdirectories; Catalin thinks they should not. What I meant by "cumulative" (now I realize I might have misunderstood what Pasky wanted to mean by that word, though) was not just .gitignore in subdirectory being added, but the effect of patterns being added so far, either from the command line or by parent directories, last while in the deeper directories. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
On Mon, 25 Jul 2005, Junio C Hamano wrote: > > I personally do not have preference either way, but am slightly > biased towards the "cumulative" behaviour the patch attempts to > implement, which was what Pasky said he wanted to have. I think that makes sense. Imagine, for example, that you have separate subdirectory structures for Documentation and for source - maybe you'd put the "*.o" rule in the source directory, and a "*.1" rule in the Docs subdirectory. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Marco Costalba <[EMAIL PROTECTED]> writes: > Peraphs, if the file name of excluded list is the same for each directory, > e.g. .gitignore or something similar, instead of --exclude-per-directory > we can use a concept of file validity 'scope' and just use > --exclude-from=. > If entering in a directory is found its contents are appended and > removed when leaving directory. A bad analogy can be with the use of > recursive Makefile. I do not know if you noticed it, but the patch already have the concept of "scope". If a pattern has a slash '/' it is scoped to the named directory by using FNM_PATHNAME. "The named directory" for command line --exclude and --exclude-from are relative to the project top while it is relative to the directory the file being used is in for --exclude-per-directory case. > If we use the 'scope' logic we can just prepend path when adding entries > and serach with with FNM_PATHNAME flag. You suggest to always use FNM_PATHNAME by adjusting the pattern by prefixing the scope. While that can theoretically be made to work just as the posted patch does, you need to realize it is a lot more cumbersome to deal with metacharacters in pathnames your way. If the prefix you need to add (because you are now looking at a path for that directory which has a funny name) is "foo*bar", you need to add "foo\*bar" to the pattern in order to make sure that the asterisk is not used to match anything other than a literal asterisk, for example. You could argue that nobody should use funny characters in pathnames, and you could further argue that current Porcelains do not handle certain characters in pathnames anyway so why bother. But ls-files being core, which is "the funny filesystem layer to build SCM on", I would like to be careful not to be unnecessarily restrictive. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Catalin Marinas <[EMAIL PROTECTED]> writes: > I think it would make more sense for the exclude-per-directory > patterns to be local to that directory only, without recursively > preserving them for subdirectories. I personally do not have preference either way, but am slightly biased towards the "cumulative" behaviour the patch attempts to implement, which was what Pasky said he wanted to have. Date: Fri, 22 Jul 2005 22:59:48 +0200 From: Petr Baudis <[EMAIL PROTECTED]> Subject: Re: [PATCH 1/1] Tell vim the textwidth is 75. Message-ID: <[EMAIL PROTECTED]> > *3* .gitignore in the cwd is used in Cogito, if I am not > mistaken. Yes. There were several discussions about this in the past, with no clear outcome, IIRC. I would prefer: ~/.git/ignore per-user /.git/ignore per-repository .gitignore per-directory (cummulative with parent directories) >> An exclude pattern is of the following format: > [...] > > That's fine. Actually, the Porcelain would care much about it since it > gets the information already filtered by git. Your saying "fine" is a relief. This change aims at helping Porcelain people by making it less likely for Porcelain to need its own filtering. As you say, if ls-files filters more than the Porcelain wants, that's a bigger problem. >> $ cat Documentation/.gitignore >> # ignore generated html files, >> # except foo.html which is maintained by hand >> !foo.html >> *.html > > Wouldn't it be clearer to have the general rules first (*.html), > overridden by the more specific ones (!foo.html)? Just my opinion, I > don't know what others think. I do not know, either, but I do know it is consistent with the "first match determines fate" rule and cleaner to implement. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Junio C Hamano <[EMAIL PROTECTED]> wrote: > * When --exclude-per-directory= is specified, upon >entering a directory that has such a file, its contents are >appended at the end of the current "list of patterns". They >are popped off when leaving the directory. [...] > A pattern specified on the command line with --exclude or read > from the file specified with --exclude-from is relative to the > top of the directory tree. A pattern read from a file specified > by --exclude-per-directory is relative to the directory that the > pattern file appears in. I think it would make more sense for the exclude-per-directory patterns to be local to that directory only, without recursively preserving them for subdirectories. One would, in general, put the common exclude patterns like *.o *~ etc. in the global file (.git/exclude). The patterns local to a directory only (take the vmlinux file for example), one would write it in the .gitignore file but this should be used for subdirectories. > An exclude pattern is of the following format: [...] That's fine. Actually, the Porcelain would care much about it since it gets the information already filtered by git. > $ cat Documentation/.gitignore > # ignore generated html files, > # except foo.html which is maintained by hand > !foo.html > *.html Wouldn't it be clearer to have the general rules first (*.html), overridden by the more specific ones (!foo.html)? Just my opinion, I don't know what others think. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Marco Costalba <[EMAIL PROTECTED]> writes: > Are really necessary to have both --exclude-from= and > --exclude-per-directory= ? > > Peraphs, if the file name of excluded list is the same for each directory, > e.g. .gitignore or something similar, instead of --exclude-per-directory > we can use a concept of file validity 'scope' and just use > --exclude-from=. > If entering in a directory is found its contents are appended and > removed when leaving directory. A bad analogy can be with the use of > recursive Makefile. Pasky wants to have one of the files in ~/.git-something if I understand correctly. I did not want to remove --exclude-from for that reason. > If we use the 'scope' logic we can just prepend path when > adding entries and serach with with FNM_PATHNAME flag. And I wanted for people's script and existing ignore files to continue to work. > Same comment as above, if prepending path when adding per > directory contents we can simplify to always use FNM_PATHNAME flag. Yes, but that means you need to always prepend the current directory being looked at to get the original behaviour. The way it was originally done without FNM_PATHNAME was far easier to read, at least for me. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] extending git-ls-files --exclude.
Junio C Hamano wrote: >The list of patterns that is in effect at a given time is >built and ordered in the following way: > > * --exclude= and lines read from --exclude-from= > come at the beginning of the list of patterns, in the order > given on the command line. Patterns that come from the file > specified with --exclude-from are ordered in the same order > as they appear in the file. > > * When --exclude-per-directory= is specified, upon > entering a directory that has such a file, its contents are > appended at the end of the current "list of patterns". They > are popped off when leaving the directory. > Are really necessary to have both --exclude-from= and --exclude-per-directory= ? Peraphs, if the file name of excluded list is the same for each directory, e.g. .gitignore or something similar, instead of --exclude-per-directory we can use a concept of file validity 'scope' and just use --exclude-from=. If entering in a directory is found its contents are appended and removed when leaving directory. A bad analogy can be with the use of recursive Makefile. > >A pattern specified on the command line with --exclude or read >from the file specified with --exclude-from is relative to the >top of the directory tree. A pattern read from a file specified >by --exclude-per-directory is relative to the directory that the >pattern file appears in. > If we use the 'scope' logic we can just prepend path when adding entries and serach with with FNM_PATHNAME flag. > - if it does not contain a slash '/', it is a shell glob > pattern and used to match against the filename without > leading directories (i.e. the same way as the current > implementation). > > - otherwise, it is a shell glob pattern, suitable for > consumption by fnmatch(3) with FNM_PATHNAME flag. I.e. a > slash in the pattern must match a slash in the pathname. > "Documentation/*.html" matches "Documentation/git.html" but > not "ppc/ppc.html". As a natural exception, "/*.c" matches > "cat-file.c" but not "mozilla-sha1/sha1.c". > Same comment as above, if prepending path when adding per directory contents we can simplify to always use FNM_PATHNAME flag. We don't have even to special case base directory global scope if we use realtive paths so that we prepend its contents with ./ and we have what we expect. I am sorry to not be able to send a patch, better explaining what proposed but I am just leaving today and I will be off line for a couple of weeks. Marco __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] extending git-ls-files --exclude.
Petr Baudis <[EMAIL PROTECTED]> writes: > Yes. There were several discussions about this in the past, with no > clear outcome, IIRC. I would prefer: > > ~/.git/ignore per-user > /.git/ignore per-repository > .gitignore per-directory (cummulative with parent directories) > > Note that I also want to make use of some special characters in this > file ... to make it at least as powerful as CVS' ignore. I'd like to extend "--exclude" and friends git-ls-files takes the following way (strawman). I'd appreciate your input from the perspective of Porcelain writers, and somebody who ends up having to use the bare Plumbing. I'll be sending patches for actual implementation in separate messages. 'git-ls-files' can use a list of "exclude patterns" when traversing the directory tree and finding files to show when the flags --others or --ignored are specified. These exclude patterns come from these places: (1) command line flag --exclude= specifies a single pattern. (2) command line flag --exclude-from= specifies a list of patterns stored in a file. (3) command line flag --exclude-per-directory= specifies a name of the file in each directory 'git-ls-files' examines, and if exists, its contents are used as an additional list of patterns. An exclude pattern file used by (2) and (3) contains one pattern per line. A line that starts with a '#' can be used as comment for readability. The list of patterns that is in effect at a given time is built and ordered in the following way: * --exclude= and lines read from --exclude-from= come at the beginning of the list of patterns, in the order given on the command line. Patterns that come from the file specified with --exclude-from are ordered in the same order as they appear in the file. * When --exclude-per-directory= is specified, upon entering a directory that has such a file, its contents are appended at the end of the current "list of patterns". They are popped off when leaving the directory. Each pattern in the pattern list specifies "a match pattern" and optionally the fate --- either a file that matches the pattern is considered excluded or included. By default, this being "exclude" mechanism, the fate is "excluded". A filename is examined against the patterns in the list, and the first match determines its fate. A pattern specified on the command line with --exclude or read from the file specified with --exclude-from is relative to the top of the directory tree. A pattern read from a file specified by --exclude-per-directory is relative to the directory that the pattern file appears in. An exclude pattern is of the following format: - an optional prefix '!' which means that the fate this pattern specifies is "include", not the usual "exclude"; the remainder of the pattern string is interpreted according to the following rules. - if it does not contain a slash '/', it is a shell glob pattern and used to match against the filename without leading directories (i.e. the same way as the current implementation). - otherwise, it is a shell glob pattern, suitable for consumption by fnmatch(3) with FNM_PATHNAME flag. I.e. a slash in the pattern must match a slash in the pathname. "Documentation/*.html" matches "Documentation/git.html" but not "ppc/ppc.html". As a natural exception, "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c". An example: $ cat .git/ignore # ignore objects and archives, anywhere in the tree. *.[oa] $ cat Documentation/.gitignore # ignore generated html files, # except foo.html which is maintained by hand !foo.html *.html $ git-ls-files --ignored \ --exclude='Documentation/*.[0-9]' \ --exclude-from=.git/ignore \ --exclude-per-directory=.gitignore - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
