I am now tired of updating my dist.ini’s for my Dist::Zilla projects. For many people this is when they start using a PluginBundle with their authorname. I discussed why you shouldn’t do this a year ago. Now that I’m tired of managing my dist.ini’s on an individual basis I’m going to show you how I’m going to solve the same problem everyone else is, which is getting tired of updating your dzil configuration for all of your projects. I’m using git to do it. You probably haven’t considered this, or am thinking I’m wrong because you believe that git can’t merge branches without a common history, which is not true. I did it with Regen2, Funtoo, Portage, and Sunrise, which have way more files than any perl repo, including Perl.First let’s talk about the advantages and disadvantages of doing this with git.I’ll start with the disadvantages. You’ll have another repository to manage. Git isn’t completely automatic, you’ll have to remember to merge your changes. You’ll also have to add the repository to your existing repositories. You will have to resolve merge conflicts at least once, and probably occasionally more, though most should be fast-forwards.The advantages are… now the changes to your dist.ini are getting recorded in your history. You can now have a master dist.ini, but remove items without filters in your individual modules. You can share even more configuration as merged differences allow you to maintain differences in downstream commits. It doesn’t automatically update all of your modules. Wait didn’t I list that last one in disadvantages? Yep, it’s an advantage because what if you update your PluginBundle and that update breaks one of your modules, but you don’t know it because you haven’t worked on that module in a while. You can use this for more than just dist.ini.Ok so the first thing you you want to do is create your master dzil repo. This is not a git or dzil tutorial so go do that. I did it by creating a dzil new project and removing the files I couldn’t use and making a few tweaks and amending all of those changes to the initial commit. Check out my repo for inspiration. Remember the directory structure has to be the same as a dzil repo structure for any common files.Now add a remote from your new repo to an existing dzil project. Next you need to merge the branch from the remote into your project. The first time you do this you’ll have to resolve conflicts. If they’re like mine then they’ll be easy and obvious. Once that’s done future changes will be fast-forwards unless you change something in your perl module repo, then you might end up with a simple merge conflict. One thing to remember NEVER EVER try to merge from your module repo to your dzil repo, it will cause you extreme pain in the future. cherry-picking that direction is possible but not merging.After that, all that is left to do is run your dzil tests and fix any breakage in your module. Happy merging.– This work by Caleb Cushing is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.