Hi All, I just had one of those "huh?" moments followed by an "oh, that makes sense" and I wanted to document what I found.
I was trying an alternative to Dan's proposal for merging pull requests ( http://mail-archives.apache.org/mod_mbox/incubator-quarks-dev/201603.mbox/browser). Instead of checking out the branch to merge, merging it with master, and then pushing it to the Apache repo, I would instead check out the branch to merge, rebase on top of master, and then push it to the Apache repo. In other words, I was doing the following: # Rebase on to master git checkout branch_to_merge git rebase master # Bring master up to date git checkout master && git rebase branch_to_merge # Push git push apache master What I found using this method was that the asf-git bot would not close the pull request on github. I found this odd, given that the changesets were identical ("huh?"). I then realized that by rebasing the branch on top of master, it had changed the commit hashes of the commits in the branch to merge. As in, if I have these two branches: <added stuff> c37ah02 --- <added more stuff> d02e0f4 (master) \--- <bugfix> f97b421 (branch_to_merge) If I rebase branch_to_merge onto master, I would get something like the following: <added stuff> c37ah02 --- <added more stuff> d02e0f4 (master) --- <bugfix> 41a4ef7 (branch_to_merge) Notice how commit hash of <bugfix> changed. I think the asf-git determines which pull request to close by looking at commit hashes; it doesn't consider the changesets. This makes complete sense after realizing it ("oh, that makes sense"). The takeaway is that I think this is a point in favor of Dan's proposal. Rebasing commits that exist outside of your repository can have side effects; merging doesn't have that issue. It's true that merging branches with master creates an additional empty commit, but it does guarantee that asf-git will function as expected. -Will
