[RFC] Thoughts on ignore files

Rusty Russell rusty at rustcorp.com.au
Mon Sep 21 11:05:19 BST 2009


On Sun, 6 Sep 2009 10:37:09 am Ian Clatworthy wrote:
> Jelmer Vernooij wrote:
> > At the moment ignore files in the three major distributed version
> > control systems (git, mercurial, bzr) are versioned inside of the tree.
> > The names and syntaxes of these files are different, so it is not
> > possible to import data from one system and then have ignores work
> > magically on the other.
> > 
> > If you convert e.g. a mercurial branch to a bazaar branch you end up
> > with a .hgignore file that Bazaar will not use. Converting this file to
> > a .bzrignore file on the fly seems ideal but is not possible for a
> > couple of reasons:
> > 
> >  * there is no one-to-one lossless back and forth mapping (and not
> > losslessly mapping would mean breaking referential integrity)
> >  * what if a .bzrignore file is already present?
> > 
> > Right now the working tree determines what format ignore files are
> > supported. It would be nice if Bazaar could support reading and updating
> > whatever ignore file is present rather than supporting just .bzrignore.
> > This could for example be done through a registration mechanism.
> > 
> > Of course, it would still be nice if ignores could be tree metadata
> > rather than part of the tree contents. This proposal does not conflict
> > with such a change.
> > 
> > Thoughts?
> 
> Speaking to Rusty a few years back at a conference, I'm pretty sure he
> had put some thought into getting bzr/git/hg all supporting a common
> .vcsignore spec. I'm not sure how far he took the idea. Rusty?

Yep, .vcignore.  Mercurial was reluctant to take the hit for per-directory
ignores, and there's always the question of unignores.

IMHO, per-dir is pretty much a requirement for large projects (eg. linux
kernel), but we could make it conditional on there being a top-level
.vcignore file.

Unignore is interesting, but AFAICT not vital: the general semantics of
ignore files only applies to untracked files.

Here's a summary of each vc's features:

      Filename      Type       Default   Comment  Subfiles   Separator  Unignore  
                               Patterns? Char
cvs   .cvsignore    fnmatch    Y         None     Yes[1]     Space/NL   ! = reset
svn   svn:ignore[2] fnmatch    Y         None     Yes[2]     NL         No
git   .gitignore    fnmatch[3] N         #[6]     Yes        NL         !<pattern>
hg    .hgignore     regexp[4]  N         #[6]     No         NL         No
bzr   .bzrignore    fnmatch[5] N         #[6]     No         NL         No

[1] .cvsignore files only apply to the current dir, not subdirs.  There
    are various options for global cvsignore files.
[2] An SVN property on a dir, not an actual file.
[3] Trailing / means dir only, no (other) slashes means basename match,
    otherwise it * won't match a / (ie. FNM_PATHNAME).
[4] "syntax: glob" lines can change this from then on int the file.
[5] Extended fnmatch (**), / implies FNM_PATHNANE, and "RE:" prefix for regex. 
[6] Everyone allows \# to escape the #, though [#] would also work.

Cheers,
Rusty.



More information about the bazaar mailing list