On Oct 09, 2016, at 12:43 PM, Nick Coghlan wrote: >It probably makes more sense to assume a successful backport as the >default case
We'll have to see. Maybe Python's code won't change so much between major versions, but I've been on projects where refactorings and other changes do result in most cherry picks needing massage. >, and cover "git commit --amend" to handle the case where the tests fail - >the ease with which history can be rewritten prior to publication is the main >UX benefit git offers over hg, so we may as well take advantage of it. Yeah; I have a visceral reaction to history modification, but git does seem to be more amenable to that. I can't check now, but what's the failure mode if you --amend a pushed commit? IIRC, the --amend succeeds but you'll get an error on push, which IMO is later than it should be (i.e. git probably should disallow --amend on published commits). >That is, there are 3 reasonably common possible flows: > >- backport with no merge conflicts, tests pass (default flow) >- backport with merge conflicts (git will prompt for this) >- backport with test failures (cover with "git commit --amend") > >Recommending "--no-commit" as the default makes the first flow longer >by adding a separate commit step without actually simplifying the >others. That's true, but I generally always want to review what git does before I publish it, and not committing makes that easier for me. The other thing is that there are lots of ways to accomplish things in git, and everyone will have their favorite workflow. That's totally fine as long as things stay local. It's okay to be opinionated and document the expected common good path, but most important is to document anything that will have global effects, because that affects everyone. Maybe think about using words like MUST and SHOULD to delineate the difference (a la RFCs). Cheers, -Barry
pgpg1rtiyMgUy.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