Skip Menu |

This queue is for tickets about the Dist-Zilla-Plugin-Git CPAN distribution.

Report information
The Basics
Id: 101223
Status: rejected
Priority: 0/
Queue: Dist-Zilla-Plugin-Git

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [Git::Commit] adds all dirty files it sees, rather than respecting 'allow_dirty'
See the history in https://github.com/Perl-Toolchain-Gang/ExtUtils-Manifest/commits/master -- After the release, [Git::Commit] ran with the following config: [Git::Commit / bumped $VERSION after release] add_files_in = . allow_dirty = Changes ; for now, there is no change here - it was committed in the release snapshot allow_dirty_match = ^lib commit_msg = After release: bump $VERSION and timestamp Changes Which *should* have only committed the 'Changes' file and lib/*, but it also managed to grab its own DZP-git.* scratch file and commit that as well! It looks like the problem is on line 71, where the list of dirty files is used as the basis for what to add - rather than the allow_dirty_* configs. (You shouldn't need to get the list of dirty files at all - just try to add everything referenced in allow_dirty_*.)
I believe this is by design. allow_dirty refers to files currently tracked by Git that are in a modified state. But add_files_in refers only to untracked files that should be added to the repository. It has nothing to do with allow_dirty. Why are you using "add_files_in = ." in the first place? You don't appear to be generating any files that need adding.
On 2014-12-31 11:41:42, CJM wrote: Show quoted text
> I believe this is by design. allow_dirty refers to files currently > tracked by Git that are in a modified state. But add_files_in refers > only to untracked files that should be added to the repository. It > has nothing to do with allow_dirty. > > Why are you using "add_files_in = ." in the first place? You don't > appear to be generating any files that need adding.
You're right! I must have been thinking that 'add_files_in' was the root used by allow_*, rather than being a separate option (combined with me using add_files_in => '.' in my plugin bundle, correctly in that case). Closing; sorry for the bother!