[core-workflow] PEP 512: migrating hg.python.org to GitHub

Chris Angelico rosuav at gmail.com
Sun Jan 17 21:57:56 EST 2016


On Mon, Jan 18, 2016 at 7:48 AM, Brett Cannon <brett at python.org> wrote:
> Luckily, Git [#git]_ does not require GitHub's workflow and so one can
> be chosen which gives us a linear history by using Git's CLI. The
> expectation is that all pull requests will be fast-forwarded and
> rebased before being pushed to the master repository. This should
> give proper attribution to the pull request author in the Git
> history.
>
> A second set of recommended commands will also be written for
> committing a contribution from a patch file uploaded to
> bugs.python.org [#b.p.o]_. This will obviously help keep the linear
> history, but it will need to be made to have attribution to the patch
> author.

Point to note: If you want to make use of git's separate author and
committer records (so the author is the person who wrote the original
patch, and the committer is the core dev who actually pushed it),
you'll forfeit the identifiable hashes on commits. Every commit will
have to be rebased (or amended, which is a short-hand form of rebase)
to change its committer, which creates a brand new commit with a new
hash. GitHub won't recognize the push as incorporating the original
commit, and neither will people's tools elsewhere.

IMO this is a worthwhile trade-off, but it is a cost, and may be worth
mentioning in the PEP. It's no worse than the current state (where a
Mercurial commit completely loses track of its original author, unless
it's mentioned in the human-readable message), but it's perhaps not
what people will be expecting.

(Also, when it comes time to write up the actual commands for people,
it'll need to be made clear that an actual fast-forward isn't
acceptable, as it won't update the committer. Amending or rebasing
MUST be done.)

ChrisA


More information about the core-workflow mailing list