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

[Matthias Bussonnier]

> On Jan 18, 2016, at 10:45, Brett Cannon <brett at python.org> wrote:
> 
> 
> 
> On Sun, 17 Jan 2016 at 18:58 Chris Angelico <rosuav at gmail.com <mailto:rosuav at gmail.com>> wrote:
> On Mon, Jan 18, 2016 at 7:48 AM, Brett Cannon <brett at python.org <mailto: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 <http://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.
> 
> I don't quite follow this. If you do a ff + rebase for the final commit how does that affect the hash of the final commit? Or what if you take a patch, apply it, and as part of the `git commit` command you specify the author on the command-line? I understand how it would change things if we were updating a pre-existing Git repository, but I'm only talking about future commits and not necessarily trying to retroactively do this for the direct migration of a repository.
> 

I think what is ment here is that GitHub has some features that allows you to go from commit number to which PR it originate from.
When you rebase to avoid merge commit, you will generate new commit hashes, which will make these functionality not work. 

You can see an example here[1], for example the the indicator  `master (#9124)`, indicate that this commit was merged into master by PR #9124.
this is typically useful to get back to the discussion/review of the PR. 

The other thing you might loose is the auto closing of Pull-requests once the commit. 

You will lose also other nice things like intermediate CI status on commit, but that’s less interesting that above features.
Agreed that might seem not that useful, but greatly improve some tasks from time to time.


-- 
Matthias

[1]: https://github.com/ipython/ipython/commit/de68bf5d79f4df17dd8989e0b1a85ed3af6ef330 <https://github.com/ipython/ipython/commit/de68bf5d79f4df17dd8989e0b1a85ed3af6ef330>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160118/3237907a/attachment.html>