Like I implied in my reply to GP, this is to cover for deficiencies in the language, tools and environments. If you can't incorporate this common logic by refer

Like I implied in my reply to GP, this is to cover for deficiencies in the language, tools and environments. If you can't incorporate this common logic by reference, then it's a deficiency of the tool(s). There's no first principles reason why you can't name a common config for ignoring git files, and incorporate it by reference--either git does not have this affordance or you haven't found it. There's no reason you can't apply principles of software reuse to CI configs for similar pipelines: Screwdriver does it, for example. If other CI tools don't, that's a deficiency. Licenses, frankly, are the same; they need to be incorporated as text in releases and distributions, but they could exist as references in whatever you consider your "original source" (and often actually do).[1] Of course, you don't always get to choose or modify everything about your environment, like how git works, how your CI is configured, etc. But it's not a bad thing to admit that scaffolding is at best a papering-over of deficiencies in these tools, and not a desirable thing in itself. I'm not familiar with Yeoman, but like other necessary but dirty things we do, we should at least try to encapsulate it and do some implementation hiding. You wouldn't generate language bindings from protobuf and then manually modify them--and the same kind of discipline should hold for these scaffoldings. You should be able to repeatedly regenerate all their artifacts (even if they get checked in) with confidence--and once you've done that, you have effectively removed the "scaffolding" and replaced it with a build tool. ---- [1] As a bit of a tangent, there's an even worse sin lurking here, which is that you have the same fact but need to capture it twice (or more) in different places: in package metadata, however you do that in your language; possibly in project metadata (if however you host your project doesn't discover it); and in the text of the license that must be distributed. If you don't rely on a single source of truth for this, you're asking not just for an ergonomic problem with updating your scaffolding, but an actual, material inconsistency, like when the COPYING file contains a different version of a license than the one that's referred to in your .gemspec. I point this out as a conceptual detail, not because I think it's an actual frequent problem.