[core-workflow] instructions for cherrypicking a change from master

[Barry Warsaw]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161009/0ca1bafc/attachment.sig>