On Dec 14, 2015, at 09:16 PM, Nick Coghlan wrote: >GitLab actually have a useful page discussing some of the trade-offs of >different git workflows: http://doc.gitlab.com/ee/workflow/gitlab_flow.html
Yep, this is a good page for the start of a discussion we're going to need to have. IMO, it doesn't focus enough on projects like Python where we don't deploy anything but instead release regular products like tarballs. Picking a code hosting strategy will be the "easy" part of Brett's work <wink>. Trying to figure out the best workflow for git-based CPython development will be the "fun" part, and the current Mercurial flow is probably not the best approach if and when git is adopted. >One of the points they make regarding "no commits to master, only >merges" is that it means that regardless of whether you're working on >a simple change that can be handled on a single commit, or a >multi-commit feature branch, there will always be a single merge >commit at the end, and that's what you revert if you decide to back >out the change - you never need to ask the question "Are there >multiple commits I need to revert in order to back that change out?". Right, that's definitely an advantage of no-ff merge commits. It's less of a concern when you have to branch locally to clean up contributions because at the end of that process, you can rebase and squash on master, and then you've only got one commit to ff. This rebase is safe because it's never pushed. E.g. Alice submits a merge request that fixes bug #3. She doesn't include a NEWS item, and her branch has some minor style issues that need cleaning up, but it's generally pretty good. Rather than nitpick Alice's contribution, Bob fetches Alice's branch, does a few more commits locally to clean things up, and then rebases his local copy of Alice's branch onto master, squashing commits. Everything looks good to Bob so he ff-merges his local branch onto master, and pushes master. In this case, linear ff-merges are cleaner and just as easy to revert as a merge-commit. It also makes it easy to cherry pick this change into stable release branches. In fact, we may find that bug fixes typically work this way anyway because if they need to be backported, it can be easier to work out all the cherry picks and do local testing on all the stable branches, then only push master and the stable branches once everything's sorted out. CI and the buildbots would then run on the results and ensure everything still works. For this reason, I'm a fan of a master-first development for bug fixes, with cherry picking to backport fixes to stable branches as appropriate. I'm love to hear about alternatives, but after a lot of experimentation, this seems to be an approach that usually works smoothly and is the easiest to understand what happened after the fact, but it's different than our current Mercurial workflow. Feature branches will work differently because they won't be backported. In those cases, an auto-merge with or without merge commits via the web ui could be a cleaner workflow. >If we were to adopt the "commit to master and backport" model for maintenance >branches, then filtering out merge commits to master should also eliminate >most of the clutter from "git log", while still presenting the meaningful >changes to each branch. There's probably no easy way to eliminate manual, local work on the part of the final committer for backporting changes from master into stable branches, but with a careful strategy, it's not that hard either. Sometimes there's no way around merge conflicts though. Cheers, -Barry
pgpElZ_dPDPtb.pgp
Description: OpenPGP digital signature
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
