Performance testing of ignore changes?

[John Whitley]

John Arbash Meinel <john <at> arbash-meinel.com> writes:

> [Lots of good info on timing.]

Great, thanks.  I'll dig into that and see what shows.

> Another possibility is to have exact matches take precedence over
> pattern matches. So if you have:
> 
> # ignore everything
> *
> # but not foo
> !foo.html
> # Locally, we want to version build results
> !**/*.o
> # But not this one
> foo/bar.o
> 
> So the priority checking would be
> 
> 1) Pattern matching ignores
> 2) Pattern matching don't-ignore
> 3) Exact matching ignores
> 4) Exact matching don't-ignore
> 
> *I* probably prefer that to !! syntax.

I'd thought of specificity-based ranking, but that seemed suspect in terms of
being computationally more expensive and maybe not user transparent.  My initial
implementation was purposely biased to be a simple extension of the existing
code.  This is an interesting compromise, but it doesn't cover cases like this:

---
# ignore everything
*
# but not ~/local/share/emacs
!~/local/share/emacs
!~/local/share/emacs/**/*
# but leave out generated .elc files
~/local/share/emacs/**/*.elc
---

I think this would need specificity-based ranking and a clear definition of
'specificity' (and/or 'explain' code in the bzr ignore UI) to work as expected.
 The '!!' (or equivalent) syntax has the benefit of being explicit.  I don't
mind implicit (aka 'magic') so long as the semantics are clear and it creates a
great user experience.  It's not yet clear to me whether that's achievable here.

-- John