kalle.niemitalo,

There shouldn't be. If the pull request's author doesn't have an email address (and a deleted user wouldn't), then the system automatically uses the person who clicked "Merge" (the pre-7.13 behavior) as the commit author instead.

Best regards,
Bryan Turner
Atlassian Bitbucket

Will there be any problem when merging a pull request whose author has had their user account deleted already?

From 7.13.0, the author of a pull request merge commit will be the author of the pull request, and the committer of the commit will remain the user who pressed the merge button. This is also the case for pull request suggestions; the comment author is the author of the suggestion commit, and the user pressed 'accept' is the committer of the suggestion commit.

This behaviour can be changed by configuring the property pullrequest.merge.commit-author to ACTOR (instead of the default value of AUTHOR). This can also be changed for suggestions by setting the property pullrequest.suggestions.commit-author.

+1 this needs to be addressed. Make it configurable!
We shouldn't have to pay for another plugin for this feature (the plugin: https://marketplace.atlassian.com/apps/1214545/pr-booster-for-bitbucket-server?hosting=server&tab=overview)

The use case at my company is, that we have created a "bot" which takes care of the Merge action automatically via the API.
We use the merge strategy "Squash merge - fast forward only".

This means, that eventually every line in our Git blame will have the "bot" user as author.
We would very much like the option to have the PR author set as author of the squashed commit. Maybe configurable from the API

I'm tired of this. Why Atlassian still not fixed so obvious thing?

This page is about the cloud version of Bitbucket, right? So I raise the simple question why does the Cloud version support it and the server version not? The need is the same in both versions. For us, it currently means that the Reviewer of the PR cannot merge but only accept it and the original author of the code has to merge it to preserve the authorship. In case the original author is out of office (sick / vacation / business travel), we only have the choice to wait until he is back, forfeit the author information or do it without Bitbucket. I do not unterstand why the solution implemented in the cloud version is not ported to the server version.

mfriedrich

You can though look at how Github does it, i believe they have a bigger user base and they seem to pretty Ok with using the PR author.

As should be expected, we're aware of how they do it. But going from one non-configurable behavior to a different non-configurable behavior after 6+ years is simply not a good product decision. All that's going to result in is the inverse of this request, where a group of (likely equally frustrated) users ask for the behavior to be changed back. The correct solution here is to make the behavior configurable, so that those who want the functionality the current way can keep it that way and those who want to change it can do so.

To be very clear: I'm advocating internally in support of this change. You don't need to sell me on it; I'm already in favor.

Best regards,
Bryan Turner
Atlassian Bitbucket

Please take a moment and re-read what I said, because I didn't make any such argument. The question was "in which context ... would this be valid?" and I provided an answer: When the two users are the same. I then explicitly acknowledged that that workflow was not viable for everyone, and wouldn't be a viable workaround. I do, however, think that the merge-your-own-pull-request workflow is likely part of the reason why this issue isn't more heavily voted for: Teams using that workflow don't notice that the merger is currently the author and committer because even if the pull request author was used they would see the same end result.

I quoted you. But i think you did not understand what i meant. Granted, you explained a scenario where the bug is hidden. But it is hidden only when the merging person is identical with the PR author.

In the scenario where they are not identical, you do something unexpected: You do not use the author of the PR as the author on the resulting squashed commit.

https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History
"You may be wondering what the difference is between author and committer. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author, and the core member as the committer."

Git blame uses the author information, specified here:

https://git-scm.com/docs/git-blame

Just to have something to compare:

It seems Github has similar discussions ongoing, But they added the co-author feature https://github.blog/2018-01-29-commit-together-with-co-authors/ which at least shows the info in the merge commit message. This would not solve the broken git-blame though.

Github seems to handle this a bit better though:
https://github.com/python/miss-islington/issues/16
I have not verified it myself, but one person says Github uses the PR author and not the one who clicks merge. The behavior is not documented.

It's not a bug because it works the way we wrote it to work, and we wrote it that way intentionally.

Seems like we disagree on the definition of bug. A specification or design can have bugs too. So, lets just say, my opinion is that your specification/design has a bug.
Using the PR author seems to be common sense to me. And i really don't know why Atlassian even argues about this.

So here are workarounds:
https://community.atlassian.com/t5/Bitbucket-questions/How-to-preserve-the-pull-request-author-as-commit-author-in/qaq-p/892714

use fast-forward-merge instead of squash-merge, and do the squash ahead of time so that you can control the metadata to suit your needs.

But this is is a lot extra work for maintainers and bigger teams. It indeed literally renders the squashed merge useless: it switches to fast-forward merge.

This issue has 58 votes, out of hundreds of thousands of Bitbucket Server users. Clearly, then, not everyone would agree that this behavior should change.

You are comparing apples and oranges. I am pretty sure that the votes are not mostly from developers, but rather from a single person representing a whole company. My vote represents the voice from about 100 developers. Not each developer is willing to register and give out his email address, nor does companies want that. Atlassian protects his developers the same way. So please do not argue you would magically know what all others who don't know about this issue or haven't expressed their opinion would want.

You can though look at how Github does it, i believe they have a bigger user base and they seem to pretty Ok with using the PR author. Some, though, have the need to even go further and preserve the individual commit authors in the scenario where the PR author is different from the commit author. But this is not the topic here.