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

[Nick Coghlan]

On 10 October 2016 at 01:12, Chris Angelico <rosuav at gmail.com> wrote:
> In my experience, CPython is stable enough that you can sometimes even
> pick up a patch from *2.7* and apply it to the latest 3.x. (The
> downside of this is that some files are oddly named, eg longobject.c,
> which implements what we now call "int".) Between 3.5 and 3.6 it'll be
> even more common for a patch to apply cleanly, and shortly after a
> branch is cut (eg current 3.6 -> 3.7), near-certain.

Right, it's mainly when you collide with a refactoring that things get
painful (e.g. the SSL/TLS rebase in Python 2.7 ran into that).

In general though, we shouldn't see any more problems with cherry
picks than we see with forward merges, and there Misc/NEWS is the only
consistent source of conflicts.

> The server will want to be configured to utterly reject
> "non-fast-forward pushes"; git actually does allow you to override the
> above message ("git push --force-with-lease" and friends), but
> ultimately, it's the central server that chooses to accept or reject
> the push. It's possible, for instance, to accept a force-push on a
> topic branch but reject them on your primary branches, which would
> allow people to rebase their "proposed change" branches freely (eg to
> update them to the current codebase) without permitting any damage to
> the version branches "3.5", "3.6", "master", etc. In GitHub terms,
> this is done by protecting a branch:
>
> https://help.github.com/articles/about-protected-branches/

The fork-and-send-a-PR model makes this relatively straightforward -
folks can rebase and otherwise edit their PR branches in their own
fork freely, and then the main repo can be set to "fast forward only".

>>>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.

While the cryptic nature of the incantations counted against it in the
original head-to-head DVCS review, the relative simplicity of
combining "git diff HEAD^" & "git commit --amend" has meant I've been
markedly less averse to eager commits in git than I am in Mercurial.

> That would be a personal workflow choice, then. +1 on RFC 2119 MUST vs
> SHOULD usage. IMO the document should specify *one* recommended
> workflow, because otherwise it's just way too confusing to read; and
> then by its language, it can clarify which parts you're allowed to
> diverge from and which not.

A lot of the SHOULDs will be "Use the web-based workflow to review and
merge changes, since that offloads more of the work to automated
systems and can be done from any client device".

While there will be cases where local client usage is needed (and
generating a backport PR will be one of them, unless/until GitHub
copies GitLab's cherry-pick-in-the-web-UI feature), allowing reviews
to be done that way is mainly for the benefit of current core devs
that prefer to do their reviews locally.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia