[MERGE] bzr add should be less chatty about ignore rules

[Wayne Davison]

On Sat, May 20, 2006 at 09:47:37PM +1000, Robert Collins wrote:
> However, its quite common on (say) a kernel tree to have many source
> rules matched, and add isn't run once - its run regularly to pick up new
> files. I don't see the change in risk between printing 'x files
> ignored', and printing 15 or 20 lines of counts : I've only read the
> entire list printed once or twice, and now its just noise.

I think that there needs to be some way to output the ignored files
summarized on a per-matching rule basis so that people can see if an
extra rule has started to show up.  Perhaps the default output of the
"bzr ignored" command should be changed to output such a list, and a new
--verbose option added to make it output each file (like it does now).

Another improvement would be to add some more smarts to the add command
that would let it differentiate between files that were already-known
to be ignored, and files that were newly ignored, since these new files
are the only ones that have a big chance of being erroneously ignored.
Here's one way to accomplish this:

 - Leave "bzr add" chatty about ignored files, but only if the file is
   not in a list of known-to-be-ignored files (perhaps maintained in a
   versioned property).  If the command mentions a file that is not in
   this list, it suggests running the command "bzr ignored --new" to
   approve these new finds.  For files in the known-to-be-ignored list,
   they are summarized in a single-line count.

 - Add the "--new" option to "bzr ignored" that makes it only mention
   files that are not in the known-to-be-ignored list (summarized by
   rule without -v), and to update the list with these new names.  If a
   file should not have been ignored, the user can always explicitly add
   the file, which would also remove the name from the ignored list.

I think that this would both cleanup the output of "bzr add" and make
the interaction of new files with the ignore rules safer.

..wayne..