| CC: | lucs [...] cpan.org |
| Subject: | Git::Check allows too much (allow_dirty is now regex) |
With this commit:
https://github.com/jquelin/dist-zilla-plugin-git/commit/cbd241447d66032465a1fe69707565755fc3eb8f
Mike Friedman quietly changed the allow_dirty attribute from an exact
string match to a regex match anchored only at the end. The intention
was to allow it to work with the default config even when the dzil root
was in a subdirectory of the Git repo (e.g. git ls-files reports
"perl/Changes" instead of "Changes").
However, the result was a major change in the semantics of allow_dirty
*and this was never even documented anywhere*. The entries are now
considered to be regexps (with an implicit $ appended) and any file with
a path that matches one of the regexps is allowed to be dirty.
In particular, "allow_dirty =", which is documented to mean "no files
are allowed to be dirty" now actually means "all files are allowed to be
dirty". (As a workaround, you can use "allow_dirty = NOTHING AT ALL",
and as long as you don't have a file whose name ends with "NOTHING AT
ALL" it will work as intended.)
Also, since the entries are now regexps, "dist.ini" will also match
"dist_ini" and "example-dist-ini". (This is probably not a significant
issue, but it needs to be documented.)
I'm not sure what the best solution to this is. At the least, the match
should be anchored at (?:^|/). But this still allows things like
corpus/Test-Dist/Changes to be dirty, when that was probably not the
author's intention.
Personally, I would vote for removing the feature entirely. Go back to
an exact string match, and if somebody wants the dzil root in a
subdirectory of the repo, make them specify that in allow_dirty.
(This bug was originally discovered by Luc St-Louis. I tracked down the
cause.)