<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 18 Jan 2016 at 11:03 Matthias Bussonnier <<a href="mailto:bussonniermatthias@gmail.com">bussonniermatthias@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jan 18, 2016, at 10:45, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:</div><br><div><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" target="_blank">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></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>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.</div><div>When you rebase to avoid merge commit, you will generate new commit hashes, which will make these functionality not work. </div><div><br></div><div>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.</div>this is typically useful to get back to the discussion/review of the PR. </div><div><br></div><div>The other thing you might lose is the auto closing of Pull-requests once the commit. </div><div><br></div><div>You will lose also other nice things like intermediate CI status on commit, but that’s less interesting that above features.</div><div>Agreed that might seem not that useful, but greatly improve some tasks from time to time.</div></div></blockquote><div><br></div><div>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. </div></div></div>