On 19 January 2016 at 05:53, Brett Cannon <br...@python.org> wrote: > > On Mon, 18 Jan 2016 at 11:03 Matthias Bussonnier > <bussonniermatth...@gmail.com> wrote: >> 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.
It also falls into the category of problem that a workflow bot addresses - it just becomes a requirement for the bot to comment on and close the original PR with a reference to the commit, in addition to actually doing the commit itself. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@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
