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

[Brett Cannon]

On Mon, 18 Jan 2016 at 11:03 Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> 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> wrote:
>
>> 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.
>>
>
> 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 meant 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 lose 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.
>

That's all true and a consequence of a linear history. We will probably
need to get into the habit of pasting the resulting commit into the PR when
it gets closed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160118/887064d9/attachment-0001.html>