On Mon, Jan 18, 2016 at 7:48 AM, Brett Cannon <brett@python.org> 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 ment 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 loose 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.