<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 18, 2016, at 10:45, Brett Cannon <<a href="mailto:brett@python.org" class="">brett@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, 17 Jan 2016 at 18:58 Chris Angelico <<a href="mailto:rosuav@gmail.com" class="">rosuav@gmail.com</a>> wrote:<br class=""></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" class="">brett@python.org</a>> wrote:<br class="">
> Luckily, Git [#git]_ does not require GitHub's workflow and so one can<br class="">
> be chosen which gives us a linear history by using Git's CLI. The<br class="">
> expectation is that all pull requests will be fast-forwarded and<br class="">
> rebased before being pushed to the master repository. This should<br class="">
> give proper attribution to the pull request author in the Git<br class="">
> history.<br class="">
><br class="">
> A second set of recommended commands will also be written for<br class="">
> committing a contribution from a patch file uploaded to<br class="">
> <a href="http://bugs.python.org/" rel="noreferrer" target="_blank" class="">bugs.python.org</a> [#b.p.o]_. This will obviously help keep the linear<br class="">
> history, but it will need to be made to have attribution to the patch<br class="">
> author.<br class="">
<br class="">
Point to note: If you want to make use of git's separate author and<br class="">
committer records (so the author is the person who wrote the original<br class="">
patch, and the committer is the core dev who actually pushed it),<br class="">
you'll forfeit the identifiable hashes on commits. Every commit will<br class="">
have to be rebased (or amended, which is a short-hand form of rebase)<br class="">
to change its committer, which creates a brand new commit with a new<br class="">
hash. GitHub won't recognize the push as incorporating the original<br class="">
commit, and neither will people's tools elsewhere.<br class="">
<br class="">
IMO this is a worthwhile trade-off, but it is a cost, and may be worth<br class="">
mentioning in the PEP. It's no worse than the current state (where a<br class="">
Mercurial commit completely loses track of its original author, unless<br class="">
it's mentioned in the human-readable message), but it's perhaps not<br class="">
what people will be expecting.<br class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>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.</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 class=""></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 class=""></div><div>The other thing you might loose is the auto closing of Pull-requests once the commit. </div><div><br class=""></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><br class=""></div><div><div><br class=""></div><div>-- </div><div>Matthias</div><div><br class=""></div><div>[1]: <a href="https://github.com/ipython/ipython/commit/de68bf5d79f4df17dd8989e0b1a85ed3af6ef330" class="">https://github.com/ipython/ipython/commit/de68bf5d79f4df17dd8989e0b1a85ed3af6ef330</a></div><div><br class=""></div></div></body></html>