If the goal is to have branches that are always passing all the tests (aka ‘stable’ branches), then I don’t see any workarounds, so +1 to this.
I’d go for branch names that are less likely to be confused w/ final cassandra-X via autocomplete though: staging-2.0, staging-2.1, staging-trunk. -- AY On May 7, 2015 at 12:06:36, Benedict Elliott Smith (belliottsm...@datastax.com) wrote: A good practice as a committer applying a patch is to build and run the unit tests before updating the main repository, but to do this for every branch is infeasible and impacts local productivity. Alternatively, uploading the result to your development tree and waiting a few hours for CI to validate it is likely to result in a painful cycle of race-to-merge conflicts, rebasing and waiting again for the tests to run. So I would like to propose a new strategy: staging branches. Every major branch would have a parallel branch: cassandra-2.0 <- cassandra-2.0_staging cassandra-2.1 <- cassandra-2.1_staging trunk <- trunk_staging On commit, the idea would be to perform the normal merge process on the _staging branches only. CI would then run on every single git ref, and as these passed we would fast forward the main branch to the latest validated staging git ref. If one of them breaks, we go and edit the _staging branch in place to correct the problem, and let CI run again. So, a commit would look something like: patch -> cassandra-2.0_staging -> cassandra-2.1_staging -> trunk_staging wait for CI, see 2.0, 2.1 are fine but trunk is failing, so git rebase -i trunk_staging <ref~1> fix the problem git rebase --continue wait for CI; all clear git checkout cassandra-2.0; git merge cassandra-2.0_staging git checkout cassandra-2.1; git merge cassandra-2.1_staging git checkout trunk; git merge trunk_staging This does introduce some extra steps to the merge process, and we will have branches we edit the history of, but the amount of edited history will be limited, and this will remain isolated from the main branches. I'm not sure how averse to this people are. An alternative policy might be to enforce that we merge locally and push to our development branches then await CI approval before merging. We might only require this to be repeated if there was a new merge conflict on final commit that could not automatically be resolved (although auto-merge can break stuff too). Thoughts? It seems if we want an "always releasable" set of branches, we need something along these lines. I certainly break tests by mistake, or the build itself, with alarming regularity. Fixing with merges leaves a confusing git history, and leaves the build broken for everyone else in the meantime, so patches applied after, and development branches based on top, aren't sure if they broke anything themselves.
