<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 17 Jan 2016 at 18:58 Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 18, 2016 at 7:48 AM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> Luckily, Git [#git]_ does not require GitHub's workflow and so one can<br>
> be chosen which gives us a linear history by using Git's CLI. The<br>
> expectation is that all pull requests will be fast-forwarded and<br>
> rebased before being pushed to the master repository. This should<br>
> give proper attribution to the pull request author in the Git<br>
> history.<br>
><br>
> A second set of recommended commands will also be written for<br>
> committing a contribution from a patch file uploaded to<br>
> <a href="http://bugs.python.org" rel="noreferrer" target="_blank">bugs.python.org</a> [#b.p.o]_. This will obviously help keep the linear<br>
> history, but it will need to be made to have attribution to the patch<br>
> author.<br>
<br>
Point to note: If you want to make use of git's separate author and<br>
committer records (so the author is the person who wrote the original<br>
patch, and the committer is the core dev who actually pushed it),<br>
you'll forfeit the identifiable hashes on commits. Every commit will<br>
have to be rebased (or amended, which is a short-hand form of rebase)<br>
to change its committer, which creates a brand new commit with a new<br>
hash. GitHub won't recognize the push as incorporating the original<br>
commit, and neither will people's tools elsewhere.<br>
<br>
IMO this is a worthwhile trade-off, but it is a cost, and may be worth<br>
mentioning in the PEP. It's no worse than the current state (where a<br>
Mercurial commit completely loses track of its original author, unless<br>
it's mentioned in the human-readable message), but it's perhaps not<br>
what people will be expecting.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(Also, when it comes time to write up the actual commands for people,<br>
it'll need to be made clear that an actual fast-forward isn't<br>
acceptable, as it won't update the committer. Amending or rebasing<br>
MUST be done.)<br>
<br>
ChrisA<br>
_______________________________________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org" target="_blank">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct</a><br>
</blockquote></div></div>