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. -Brett > > (Also, when it comes time to write up the actual commands for people, > it'll need to be made clear that an actual fast-forward isn't > acceptable, as it won't update the committer. Amending or rebasing > MUST be done.) > > ChrisA > _______________________________________________ > 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 >
_______________________________________________ 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
