Performance testing of ignore changes?

John Whitley whitley at bangpath.org
Mon Jan 4 21:50:39 GMT 2010


John Arbash Meinel <john <at> arbash-meinel.com> writes:
> I'll also note that I'm not really sure how to introduce this and worry
> about backwards compatibility. If older bzr versions just ignore the '!'
> line, that might be ok, though I have the feeling they will abort, and
> possibly fail to read the whole file.

I don't know how much the implementation has changed over time, but the current
implementation would just interpret '!foo' literally and create a regexp that
matches those four characters in an attempt to ignore them.  Given the rarity of
files starting with '!', the ignore file interpretation would mostly just revert
to the existing behavior, i.e. observing only positive ignores.

Fortunately it's easy to smoke test backwards compatibility here.  Can someone
suggest an old version that's a good test candidate? (

> This is certainly more complex, and I'm not convinced it is the best way
> forward. However, it would make round-tripping the git rules easier. :)

That's an idea.  FWIW, I tried setting up nested .gitignores to do just that,
but it didn't really work as I'd hoped.  e.g.:
--- /.gitignore:
# ignore everything
*
# except local
!/local
--- /local/.gitignore
# ignore bin/bzr, because it's a system-specific softlink if it exists
bin/bzr
---

'git status' on the above with the corresponding tree doesn't show a
/local/bin/bzr file (path rooted at top of working dir) as existing.

In fact, I haven't been able to solve the problem I described using the git
ignore implementation despite having the '!' operator and nested ignore files at
hand.

I'll probably spin out a version of the ignore code with '!!' implemented to try
out.  It's easy enough to extend my work to cover that case and practical
experience with it should be useful.

-- John





More information about the bazaar mailing list