discussing ignore rules

[Wayne Davison]

On Wed, May 10, 2006 at 05:37:57PM -0700, John A Meinel wrote:
> The problem with per-user ignores is that it becomes very easy to use
> them to ignore whatever you want, but then other people grab a copy of
> your branch, and suddenly 'bzr add' adds all of the object files.

I would instead say that "bzr status" would show a bunch of unknown files
that the user did not create, at which point the .bzrignore file (or some
future versioned property) gets updated and committed (either by the new
user or by notifying the original user).  After all, surely people don't
blindly "bzr add; bzr ci -m 'Blind commit!'" without first checking what
they're about to commit.  Having a user put the wrong kind of ignore rule
into the global ignore file is something that will easily get sorted out in
any kind of a cooperative environment since it will be really obvious to
others that grab the affected project that one or more ignore rules are
missing.

The most compelling reason to me for the separate global ignore file is to
allow you to ignore things that have no direct bearing on a project.  The
aforementioned "x.patch" file that my own personal diff habits create is a
prime example of a file that has absolutely no reason to ever be put inside
a .bzrignore file -- it simply has no meaning to anyone else checking out a
branch of mine, nor do I want to have to add it to everyone else's branch
that I want to fiddle with.

Perhaps the "bzr ignored" subcommand should be extended to show which rules
came from the local file.  If a user runs this on a project and sees any
generated files matching a global rule, it would be a good indication that
the ignore rules needed some tweaking.  The easiest way to do this would be
to change the code to load the local rules first, save off the size of the
array, and then load the global (or default) rules.  Then it would be easy
to check the index of the matching rule to know where the rule came from.

..wayne..