Authorship of merge commits made by Github Apps changed?

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.

3 Likes

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!

9 Likes

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.

12 Likes

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

3 Likes

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.

12 Likes

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.

24 Likes

I think you need a web interface to git --amend to mitigate the fall-out.

Dear GH,

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.

Best,

– 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.

27 Likes

Fix deployed. Apologies again, and thanks for the feedback.

10 Likes

Thanks for reverting the change.  I am seeing the old behaviour again, as expected.  Also thanks for dropping by and keeping us informed.

1 Like

I’m not sure it has been reverted entirely to the same old behavior. Previously it would distinguish between commit author (user that created the PR) and committer (user that clicked the squash merge button), that doesn’t seem to happen now. Additionally, it seems that squashed PRs aren’t counting towards project contributions of the PR author (which was the main issue caused by this change).

Edit: contributions are being counted correctly, sorry for the noise.

1 Like

I’m not sure it is reverted entirely too. In the previous, the one who click “squash and merge” will be the “comitted”. That will also be visible in the GitHub commits page that the author and committer are different. 

However, the “committed” is always “GitHub <noreply@github.com>” now, and we can’t see the committer (who merged the PR) in the commits page any more. 

1 Like

I’m not sure it is reverted entirely too. In the previous, the one who click “squash and merge” will be the “comitted”. That will also be visible in the GitHub commits page that the author and committer are different. 

However, the “committed” is always “GitHub <noreply@github.com>” now, and we can’t see the committer (who merged the PR) in the commits page any more. 

I’m not sure it is reverted entirely too. In the previous, the one who click “squash and merge” will be the “comitted”. That will also be visible in the GitHub commits page that the author and committer are different. 

However, the “committed” is always “GitHub <noreply@github.com>” now, and we can’t see the committer (who merged the PR) in the commits page any more. 

I’m not sure it is reverted entirely too. In the previous, the one who click “squash and merge” will be the “comitted”. That will also be visible in the GitHub commits page that the author and committer are different. 

However, the “committed” is always “GitHub <noreply@github.com>” now, and we can’t see the committer (who merged the PR) in the commits page any more. 

https://github.com/randyallen19890413/github-slideshow/issues/1#issuecomment-596987511

> However, the “committed” is always “GitHub <noreply@github.com>” now, and we can’t see the committer (who merged the PR) in the commits page any more. 

This is a problem with a number of workflows and suffers from the same problem as the (much more important) change discussed here before.

In projects with multiple maintainers it *is* important who (reviewed &) committed a patch for various reasons.

As many projects actually forbid direct pushes with the advent of more and more web functionality all new commits are eventually committed by this generic user.

https://github.com/google/omaha/pull/135#issuecomment-383692850

Erm, hope you don’t mind me asking, but, how do i make stuff?