On Mon, 18 Jan 2016 at 11:03 Matthias Bussonnier < [email protected]> wrote:
> On Jan 18, 2016, at 10:45, Brett Cannon <[email protected]> wrote: > > > > On Sun, 17 Jan 2016 at 18:58 Chris Angelico <[email protected]> wrote: > >> On Mon, Jan 18, 2016 at 7:48 AM, Brett Cannon <[email protected]> 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. > > > 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.
_______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
