Code review comment for lp:~parthm/bzr/300062-better-handling-for-invalid-ignore-pattern

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Parth Malwankar wrote:
> It seem to me that the majority prefers bzr to be more forgiving about bad patterns. I can go ahead with a warning based approach if there are no objections to this over the next day or two.
>
> Here is what I understand.
>
> 1. `add` - This should fail (error) as we don't wan't to add file that the user may want to ignore

I would actually disagree and just warn. The user can always 'bzr
revert' or 'bzr rm'. Especially if they were supplying explicit paths
("bzr add foo" shouldn't care about ignore patterns, because it always
adds foo even if it was ignored.)

> 2. `ignore` - Show warning and skip any bad patterns found on the command line.
> 3. `ignored` - Try to show ignored files. If this errors out with bad regex, filter out the faulting regex(es) at runtime and retry. The disk files are not changes. Issue a warning about faulting regexes.
> 4. `status` - If we see a regex failure, filter out the faulting pattern at runtime and retry the ignored files. The retry based approach should reduce the number of 'unknown' files listed.
>
> This would also impact `ls -i/-u`. I will look into that some more. I suppose we would want a similar retry based behavior for this also.
>
> Any further thoughts/ideas about the user interaction should be? Any more commands that might be impacted?
>

I would look to do it the 'cleanest' way internally. My feeling is that
turning everything into a warning is likely to be fairly straightforward
and the most worthwhile.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwH7UQACgkQJdeBCYSNAAN3hACgvtuI/Jb1yJ8pJQPsGxwfG0f0
eF8AoI+7+E1fKzOZZ4kq3phkxCJmTEXL
=fiKw
-----END PGP SIGNATURE-----