[ajross]

Isn't that what all large projects are doing internally? Hell, big chunks of the git chrome (things like "git am", "git request-pull", "git send-email") is precisely an attempt to write scripts to automate core parts of the kernel workflow. Github added bits of its own, like "watching" a public repository and providing a core spot for pull requests to land, with discussion and review tools. I don't understand why you're so interested in "enforcement" when projects using these tools seem to be doing just fine.

What you're saying sounds to me a lot like the stuff we heard from Java nerds in the 90's (who certainly didn't invent it, Pascal and PL/1 nuts said much of the same stuff) -- the programming environment should be designed to force the user into a particular style. Our community has, for the most part, rejected that view in favor of dynamic systems with more flexibility. Why should SCM branch management be any different?

[sanderjd]

I think it's a balance. There is value in having people working on a given project aligned on the same basic workflow. To achieve that for a team that is currently growing or is planning to grow, you have to document what that basic workflow should look like. That "document" can be a set of social mores that are loosely enforced through complaint and argument, or an actual document somewhere, or a tool like your parent is suggesting.

Such a tool, which makes the preferred workflow very easy and excursions outside it achievable but somewhat more difficult seems like a pretty good idea to me, and not at all as stuffy and prohibitive as you seem to fear.

[ajross]

I don't disagree at all. But in reality, those tools exist and are all around us. What would be the value of putting that stuff into git itself? Why is it a shortcoming of git that it hasn't picked one?