Re: [RFD] Ignore rules

[David Greaves <david@dgreaves.com>]

Petr Baudis wrote:

>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

>>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.

>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.

>>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.

>>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.

>>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...

>/.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

>/.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.





--