git remote add template email@example.com:jappeace/haskell-template-project.git
git remote set-url origin firstname.lastname@example.org:jappeace/new-project.git
This allows me to keep my downstream project up to date with the template. When I discover another tool, this can be merged into the downstream project for example. It allows evolving the template over time as I learn more about whatever programming language I’m using.
It also gives me default branding. Which makes it look more ‘professional’. Although I don’t like branding, I know this is necessary. Having it there by default makes it so that I don’t forget to do this.
When starting a project you also gain some free authoritativeness, because you have a longer commit history the project looks like it is more mature. Although this practice is a little deceptive, there is a core of truth, because the template has gotten a lot of attention. If you feel offended by this practice, ask yourself first, why are you trusting git histories? These can be rewritten anyway. This authoritativeness also gives me a small moral boost. It just feels better to have a project with well thought out tools being started and some history rather then the ‘normal’ stuff everyone starts with.
The alternatives are using tools that spit out templates. In the haskell world these are stack new, cabal init or summoner. These tools are simply a glorified
sed on projects folders: They find and replace variables. There is no versioning, there is no personalization except what limited variables give.
Because these tools don’t take into account history, the first commit will be a large commit with a message like ‘Initial’. I find this problematic because it squashes all the work that went into creating the template. Information is lost, for no reason.
These tools don’t use git to track their templates. They could, but they don’t. Maybe they wanted to be VCS2 agnostic? I’m speculating, but even if you wanted to be that, you could still use any version system to track the template and recreate the history in the VCS desired by the user. This at least gives the user their history of the template back. While also giving them the choice of VCS3
A template hierarchy
What I described in the intro can be taken a step further. A template of a template can be used to create another new template. For example, say you’re a fan of nix or make, so why not put a makefile and a nix pin in some template of templates project. These tools don’t care about which language you use, so their configuration can be shared among Python, Java and Haskell projects for example. Maybe for github it could even have a partial travis or github actions CI setup.
Now, say you’re starting a new Python project, but have no template yet for that programming language. You simply clone this template of templates and customize it to your own Pythonic needs. You can still pull in the upstream changes from your template of templates, for example to upgrade the nix pin. The big advantage of course is that a change in the template of templates can easily merged into all downstream projects with git.
I convinced the reader that using git is the superior way for template management. It’s simpler, and more flexible. I also convinced the authors of stack, cabal and summoner to drop their current way of managing templates and use git instead.
Or, more likely, no-one read this far.
This started out as having no better alternative, due to my nixos choice. But now I realise, this is the best alternative. ↩
Version Control System ↩
I wouldn’t bother with this choice unless someone is asking for it. I think git has won the VCS battle by a wide margin. Of course that’s easy for me the say as neither maintainer nor user. 25% SVN market share is a lot more then I expected (the absolute SVN repo count is still going up!). ↩