i looked at the history and it seems they just close them even when they merge them, and then merge them via their own commits. but you can see them accepting stuff in the comments of the closed pull requests
Note that they have different commit references. Thus Github does not recognise this as a merge, and there's no way to explicitly tell Github that you did merge it.
Hi, there, Signal Android developer here. This is correct. Our process is that we work in a pre-release branch, and then merge that to master when we make a release. So GitHub doesn't usually recognize it as a merge, but we always keep the original authorship and whatnot.
You could include "Closes #123" or "Merges #123" or "Fixes #123" in the commit message of the merge commit, and GitHub will link it, and currently close it (it doesn't actually consider it merged, but it at least auto-closes and links)
For that to work the PR owner has to know which branch to target (assuming it's public).
Unless the PR creator somehow knows which release their PR is going to be included in, with a guarantee it'll be merged in said release, then it's just not possible for the PR creator to target the correct branch.
It’s a bit undiscoverable, but if you click the edit title button it will actually allow you to edit the base branch as well. Sibiling comment said this might be opt-out-able, but at least in ms/vscode no one seems to opt-out.
When filing a PR there's a "allow maintainers to edit the PR" checkbox (I don't recall the exact wording). If the PR owner doesn't check it, the maintainer can't change the target branch.
Hey there, would be great if you reference these merges in the issues so it would be visible to everyone (and especially the devs who put in the work) that the code is used.
I don't know but I can speculate a couple reasons why they might:
-They might not want people who aren't officially affiliated to get "contributor" badges on github, so people don't get confused thinking they speak for the project when they participate in discussions
-github may not be their primary way of managing their source, so pull requests have to be transferred to their internal system first before being released on github
-better control over what gets into what version without having to micromanage when to accept pull requests
Also helps with ownership. They have to maintain the thing, and it's easier to do when the person who committed it is a co-worker you can get a hold of.
But Git is a distributed VCS. They could just as well cleanly merge pull requests into the main branch as hosted on GitHub and then merge GitHub's main branch into their canonical system's main branch.
I just randomly picked a contribution from an external party. The commit that made it into mainline has an author set to the person that contributed the code originally and a committer set to one of the 'signal.org' members. I'm confused why people would have a problem with how they chose to manage their code if the original attribution is not lost in the process. I'm fairly certain the Linux codebase is managed similarly.
