Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

[RFD] Ignore rules

From: Petr Baudis <hidden>
Date: 2016-06-15 22:41:57

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 [off-list ref] 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?
maybe re: precedes regexp lines and unadorned lines are globs.
Or maybe even /, which is the common regexp prefix anyway...

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.
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?
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 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.
Remember that you can throw it away with !* if you don't like it.

/.git/ignore:

Per-repository ignore list, not version tracked etc; really a local thing.

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


Opinions?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help