[jjayj]

> I'm more inclined to invest time in git itself.

This is fine until you're working with hundreds of other developers. I believe the reason solutions like this exist is to abstract git away from most devs, because in (my experience) many enterprise devs have only rudimentary git knowledge.

Sure, the devs should "just learn git" - but the same argument applies to a lot of other tech nowadays. Ultimately most folks seem to want to close their ticket off and move to the next one.

Git submodules and git subtrees generally do not fit my org's needs - we have internal tooling similar to this. Happy to expand on that if you have questions.

[tjoff]

The risk with that approach is that every other of the hundreds of developers will bring their own tool for X. So now you have hundreds of tools and everyone only knows a subset.

If there is a common operation that people get wrong or don't use often enough but still need to run regularly a five-line bash script will not only do the job it will actively help them learn the tool they are using.