On Sep 3, 2014, at 8:57 AM, Jed Brown <[email protected]> wrote: > Patrick Sanan <[email protected]> writes: >>> But this was my whole point in our process discussion. Tools should >>> subtract >>> from what we have to worry about, not add to the cognitive load. We should >>> all be manually checking for less, not more. A good tool would prevent any >>> merges to master from a branch that was created from next. This seems like >>> the simplest requirement to me. > > It's not _that_ simple to define precisely in terms of the DAG.
This hits the nail on the head! The current git model is incomplete/problematic if it cannot handle such a simple and extremely important thing as “prevent some j-a- from f-ing up the master repository”. Barry > >> Should this be possible with git hooks? I've never had occasion to use >> them but naively, I'd want to do something like create a commit in >> 'next' which is tagged 'NeverMergeToMaster' > > Tags suck for this because they are not supposed to change, but 'next' > is rewound after releases. Better to use a special branch and compare > against 'origin/sentinel', but is "origin" always the name of the remote > (it's not for me)? > >> and then set up a hook which will automatically reject any merge to >> master including a commit with that tag. The practicalities aren't >> clear to me, though, since as far as I can tell BitBucket doesn't give >> you direct access to hooks, which you would probably need to employ a >> strategy like this one: >> http://stackoverflow.com/questions/13381105/git-hook-to-prevent-an-experimental-branch-pushed-to-a-release-or-master-branch > > Bitbucket and GitHub do not want to be in the business of server-side > policy because everyone wants something different and implementation is > error-prone, so it would be an endless support issue for them. We can > install hooks locally (e.g., as part of configure) if necessary, just > make sure that you run configure before merging in a repository, make > sure that the git module is loaded when you run configure so that > configure can run the git executable and correctly resolve the hooks > directory, make sure that you don't use a shared clone or other sneaky > option to have your GIT_DIR located elsewhere, don't use alternative > porcelain for making commits, and don't use the stupid Merge button on > the website. Well, I guess that's a few caveats.
