- Don't use anything that changes the line numbers of your source
- Examples: don't use DZP::Prepender. Use modules like OurPkgVersion to insert VERSION, and make sure your # ABSTRACT and any pod is below the
1;at the end of your module. This will keep the line numbers of errors in your code from being different from the final build. It's still ok to use PodWeaver as it will save you way more time than it'll hurt, so long as you follow the rules about pod being at the bottom
- Use a plugin that commits builds to your source control software
- I personally recommend DZP::Git::CommitBuild
- Make your build branch your default branch
- I'm not sure how to do this with just git, but on github you can go to the admin section of your repository and change the default branch there. This makes it so that when someone clone's your repository the initial checkout is of your build branch. Your build branch shouldn't require dzil, it's the final build.
Now that you have your final build branch as the default branch anyone who wants to contribute can simply clone your repo and start hacking. Their are a couple of mistakes they could make, They could either change or add files that are maintained, or pruned by dzil. This did happen when Schwern sent me patches, one of them was the addition of a .gitignore, which I already had, but is being pruned out of the build branch. I can also see it happening to meta's and makefiles. These patches can simply be rejected as unnecessary, dzil-ified, or if they are truly a bug, then they can be reported and fixed upstream.
So what if someone sends you a pull request from
build/master? well if it's just one or two patches, you add their remote, and do a
git remote updateand then you can
git log remote build/masterto find the sha1 of this patch. Now that you have the sha1 all you have to do is
git cherry-pick [sha1]and it should apply. If there are any conflicts you may have to resolve them with
git mergetool. However, the only conflict with Schwern's patches for me was the .gitignore, all other patches applied without assistance and applied correcly, surprisingly even the pod patch applied without issue.
If you have more patches than is comfortable with
git cherry-pickthen you need
git rebase. The command you want is
git rebase -i --onto master [sha1 before first sha1 in series] [tip of remote branch checkout]. So in my case
git rebase -i --onto master 3f1e3748 schwern. What this appears to do is ends up rewriting my local schwern/build/master checkout and removes all the build commits, and then applies the patches on top. This means I can now do
git merge schwernfrom the master branch, and all of his patches that I want will be successfully merged. For more on this strategy you may want to read this stackoverflow question.
given this is not quite as easy as a
git pullthat's a fast forward, but reality is it's not that hard once you know how to do the rebase and how it works. Of course this isn't ideal for constant contributors, those should simply learn to use dzil, but for the random contributor it should be ok.