Re: [RFD] Ignore rules
Show 18 quoted lines
>Here, I would like more people to speak up, plaese, especially the
>authors of other layers over git than Cogito, since I think it'd be
>great if we could agree on common ignore rules format and we could just
>call the files ".gitignore" instead of ".cgignore", ".jitignore" etc.
>
>
>Dear diary, on Sat, May 14, 2005 at 05:13:08PM CEST, I got a letter
>where David Greaves <david@dgreaves.com> told me that...
>
>
>>I was wondering about supporting _both_ globs and re's
>>right now my ignore file has a # to precede comment lines
>>
>>
>
>I assume \# will override that?
>
>
doesn't match /^\w#/ so yes
Show 6 quoted lines
>>maybe re: precedes regexp lines and unadorned lines are globs.
>>
>>
>Or maybe even /, which is the common regexp prefix anyway...
>
>
I thought about it but thought it would look strange since we won't want a closing / OTOH, no globs will start with a / since they have to be relative so maybe a good choice after all.
Show 6 quoted lines
>To mention it in this mail too, I think leading '!' should do the
>"ignore exclude" - that is, it would override any possible previous
>ignore decisions about the file. E.g. '!*' would throw away all
>previously applied ignore rules.
>
>
Well, CVS has a lone ! meaning just that. I wonder if we should simply say that most patterns are 'ignore' patterns. '!' patterns are 'accept' patterns. The last seen pattern wins
so given: *.o !fre*.o freddy.o
frog.o is ignored fred.o is seen freddy.o is ignored
This means !* (or is that !**) has the same effect as a lone ! in CVS.
Show 20 quoted lines
>>However the re's provided by regex(7) are too weedy to be worth
>>bothering with.
>>If however, there is a serious plan to go to perl, it may be worth
>>providing for this now in the ignore syntax.
>>
>>Also... you haven't mentioned perl for a while - can you give us an update?
>>I personally think we're making life needlessly unpleasant by sticking
>>with shell.
>>
>>
>
>If there is still a serious plan, it is much more long-term now, since
>shell turns out to keep doing fine and everything we need, and that all
>reasonably fast.
>
>That said, I think it's fine to use Perl regexps. I think they rule. :-)
>But what do others think? Should we stick with POSIX regexps (I assume
>at least extended instead of basic), or go with Perl regexps?
>
>
I vote perl re's
You have the power if needed but most of the time it'll be basic regexps.
I think if we have a central 'path' matching .git/ignore then regexps
are needed.
Then if we have them, we may as well allow them.
OTOH: A plethora of .gitignore files with the !negation mechanism may
make globs adequate.
Show 13 quoted lines
>>Additionally this causes problems with sharing the same exclude file as
>>used by git.
>>However...
>>I really think git's exclude file capability and cogito's are different.
>>Cogito is aiming to provide full-blown SCM capabilities - git isn't
>>
>>
>
>If we get to agree on some common format, I'm thinking whether it
>wouldn't be actually good to extend the --exclude option to support it.
>How much of an issue would that be? What do others think?
>
>
I'm not convinced it needs to be extended. It's trivial to take git-ls-files and filter it's results. The rest of git will need filtering.
Show 15 quoted lines
>>I am also concerned that a centralised ignore file is not flexible enough.
>>Certainly limiting if we support globs only.
>>It may be that you want different rules in different trees - someone on
>>lkml mentioned that excludes vary in different parts of the source.
>>Eg .s files may be generally ignored - but not in the asm parts of the tree.
>>
>>
>
>I imagine it as (ignore rules applied in this order):
>
><default ignore list>:
>
>Some builtin ignore list catching files like *.o, *.a and such.
>
>
Why builtin? Why not have a default setup for .git/ignore The way I'd do it is in cg-init : [ -f cogito.ignore ] && mv cogito.ignore .git/ignore [ ! -f .git/ignore ] && cat <<STD_IGNORE > .git/ignore
>Remember that you can throw it away with !* if you don't like it.
>
>
but it means reading the man pages to find it out whilst you're editing .git/gitignore I could never remember what CVS ignored...
Show 5 quoted lines
>/.git/ignore:
>
>Per-repository ignore list, not version tracked etc; really a local thing.
>
>
~/.gitignore ?? CVS has it - personal prefs for your editor's strange numbered backups etc
Show 19 quoted lines
>/.gitignore
>/**/.gitignore:
>
>(Applied in the order from the project root to the current directory.)
>
>
>Version tracked ignore list, which concerns the current directory, BUT
>may match pathnames instead of just filenames (but no ..). That is, you
>could do something like
>
> echo '*.o' >.gitignore
>
>to ignore all the object files in the current directory, and
>
> echo '**.o' >.gitignore
>
>to also ignore the object files in all the subdirectories.
>
>
well, is the matching against files or paths? And do .gitignores affect their sub-tree or just their dir? And if they're vc'ed then git needs to stop ignoring .files
>
>Opinions?
>
>
I think the global ignores contain both:
* regexps against the path relative to the project root
* regexps against the filename
* shell globs against the filename
I think the .gitignore's operate on a per-tree basis (so their directory
and lower)
I think .gitignore matching should be against filenames (not paths)
# comments /regexp !/inverted regexp shellglob !inverted shellglob
Lesson from the CVS manual: Specifying `-I !' to `cvs import' will import everything, which is generally what you want to do if you are importing files from a pristine distribution or any other source which is known to not contain any extraneous files. However, looking at the rules above you will see there is a fly in the ointment; if the distribution contains any `.cvsignore' files, then the patterns from those files will be processed even if `-I !' is specified. The only workaround is to remove the `.cvsignore' files in order to do the import. Because this is awkward, in the future `-I !' might be modified to override `.cvsignore' files in each directory.
David Greaves
