I have a Github App that calls the PR merge function in the API (with method squash). Before roughly 2020-03-04 17:55 UTC, the resulting merge commits had the person who opened the PR as author, but after that time, the merge commits have the bot name as author. Was this a deliberate change by Github?
We have a similar tool and are also encountering this issue.
It would be useful if we could specify the author via the API:
I suspect that Github considers the old behaviour to be a bug and has fixed it, and now we have to act on behalf of the user by acquiring an access token via oauth flow.
Anyone else found a solution for this?
In our org, the merges happen from one person (bot) based on the tests passed.
Now all the commits show up as if they jenkins bot authored them.
It’s not a feature, it’s a bug
hopes it could be fixed soon
We are also seeing this when squash merging PRs from contributors. Previously merged commits used to be attributed to the author of the PR, now they are attributed to the person who merged. An issue was raised with Github support.
In my project several commits lost attribution to the original author due to this very serious squash button bug.
I have also raised this issue with support.
Yes, please bring back the old behavior.
All squashed PR commits are now authored by the account that merged them, not the account that submitted the PR.
We are encountering the exact same behaviour! This is going to cause big problems in the Blame history so we hope GH reverts to the old behaviour soon.
I’ve heard back from Github support. They consider this a feature not a bug.
> This is an intentional change that our team recently deployed and I’m
> sorry to hear that’s causing trouble.
> When a user chooses to squash and merge a PR they are taking authorship
> of the commit. If they were merging the PR and creating a merge commit
> that merge commit would be attributed to them as author, so we wanted
> to be consistent with that hence the change. We are also aware that we
> should be setting the author as a co-author and we can see that’s not happening
> every time.
Well, they’re pretty clearly wrong in “wanting to be consistent with that”. Merge commits are completely different to the entire body of work that can go into a squashed PR. I probably won’t be merging (we have a strict squash merge policy) any PRs anytime soon while this is ongoing!
Thanks everyone for being here and for your feedback, I’d opened an internal issue requesting more information and adding all of your feedback about the change. As soon as I have an update from product, I’ll share it here. I understand the disruption this has caused in your workflows and appreciate your patience.
Thank you AndreaGriffiths11, I as a contributor was a little upset by this bug, because it is not visible in the graph of my work
Hi @andreagriffiths11 thanks for opening an internal thread on this so quickly!! As a maintainer of an open source project I will often squash merge community contributions not because I want to take owenership of them - that is in fact the last thing I want to do - but because the squash is a good way to keep our git history clean and those individuals often don’t have merge rights to the repository. Even in the cases where they do have merge rights, we generally find it keeps things running a bit smoother to have only one or two people actually doing the merges.
Stepping back, I’d really like to see all the people who contributed code to the PR get acknowleged as contributors for that PR and would be fine not being recongized at all as the person who just clicked the squash merge button as it massively over inflates my code contribution to the project, making it hard to tell what are my code contributions vs my maintainer contributions. Appropriately managing credit and reward is an important part of keeping these ecosystems healthy, and placing too much weight on whoever clicks the button shifts the balance in a bad direction.
Hi friends, thanks again for your patience, we are reverting this change and a deployment to fix should be out in the next couple of hours.
I think you need a web interface to
git --amend to mitigate the fall-out.
Since this has caused significant disruption, I suggest the following course of action:
1. Temporarily revert back the change for, say, 2 weeks. This will allow users to change their code to explicitly set the author without permanent impact on logs.
2. Fix the co-author bug.
3. On a pre-announced date, re-introduce the change.
– Your loving user community.
Hi friends, I’m the GitHub PM responsible for this change.
First of all, apologies for all the trouble this has caused. We’re going to revert the change, and GitHub’s squash-and-merge behaviour will be back to normal in the next 24 hours.
Our original intention with the change was to fix a couple of minor issues with the previous GitHub behaviour by bringing GitHub’s implementation of squash-and-merge in line with the behaviour of
git merge --squash, which uses the merger as the author of the squashed commit. With hindsight this was a mistake - I had not realised how much this would affect existing workflows, and in particular how it would affect the use of
git blame. In addition, the change added a bug that removed the
co-authored-by trailer in some cases, further exacerbating the issue.
Thanks you everyone who reported this, either here or directly to support, and apologies again for the trouble this has caused. We will have the change reverted in the next 24 hours and will work on alternative fixes to the minor issues with GitHub’s current implementation of squash-and-merge.
Fix deployed. Apologies again, and thanks for the feedback.
Thanks for reverting the change. I am seeing the old behaviour again, as expected. Also thanks for dropping by and keeping us informed.