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

[Brett Cannon]

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.

-Brett


>
> (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
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160118/e577cde1/attachment.html>