Is it possible to merge our 'code/PRs' and 'issues' repositories into one?

[quicksketch]

Back in May 2019, GitHub introduced a new feature for a "Triage" role that allows users to add and remove tags, milestones, and assignees but without the permission to push to the repository.

See https://help.github.com/en/articles/repository-permission-levels-for-an-organization

Way back when we set up the Backdrop repositories, we set up https://github.com/backdrop/backdrop to hold the code and https://github.com/backdrop/backdrop-issues to hold the issues, per GitHub's suggestion at the time, because there was no intermediate role available. Now that such a role exists, we could in theory get rid of the separate issues repository.

[ghost]

That would certainly simplify things... Since this is tagged as a 'question', I'll assume it's "Should we do it" and I'll say yes 🙂

[stpaultim]

I think it would be an obvious yes except for a discussion about the implications and what might get lost or confused in the process.

I'm thinking about how this might be done with minimal data/history loss.

1. Move the official Backdrop code (and commit history) into the backdrop-issues repo
2. Deleting the old Backdrop code repo
3. Renaming the issue repo to replace the old code repo. I think that it might better to keep the namespace for the code repo (backdrop-issues would no longer make sense)

What would we loose?

• All the discussion on the old PR's?
• All existing links on the web to current backdrop-issues would be broken
• How would this effect PR history?
• I assume all branches, tags and releases would survive fine (is this correct).
• What else?

[klonos]

I think that it'd be best to move the issues from this repo here, to https://github.com/backdrop/backdrop.

The issue of transferring issues (including comments) has been brought up before here (back in 2013), and one of the comments there points to this python script to get the job done: https://github.com/IQAndreas/github-issues-import (repo not updated since 2014 though):

The script from @IQAndreas is very good but doesn't preserve the original dates and users.

I wish it could, but it's just not possible with the GitHub API.

There's also mention of https://github.com/google/github-issue-mover, but that seems to have been deprecated back in 2016 😞

Perhaps we should contact GitHub support to help us out or provide info/pointers?

[klonos]

Perhaps we should contact GitHub support to help us out or provide info/pointers?

Huh, even the tread in holman/ama#413 concludes with this:

If you want to chat about this further, shoot us an email to support@github.com.

[klonos]

...other related discussions around the web:

https://github.community/t5/How-to-use-Git-and-GitHub/Bulk-Transfer-all-Issues-to-a-different-Repository/td-p/21241

As there is an api for creating and getting issues it's possible to use the API to automate creating the issues on the new repository but technically they are "new issues". There are a handful of utilities out there that can do some of the heavy lifting for you. See http://www.alexhadik.com/blog/2016/5/26/migrating-github-repositories-with-gitmover for one example.

[klonos]

Also, https://help.github.com/en/articles/transferring-an-issue-to-another-repository

...
You can only transfer issues between repositories owned by the same user or organization account. You can't transfer an issue from a private repository to a public repository.

When you transfer an issue, comments, assignees, and issue timeline events are retained. The issue's labels and milestones are not retained, although you can see past activity in the issue's timeline. This issue will stay on any user-owned or organization-wide project boards and be removed from any repository project boards.
...

...this is via the web UI though; does not mention any API way. Also, only works on open issues 😞

[klonos]

Another tool (GitHub app): https://probot.github.io/apps/move/

[quicksketch]

Note in all cases though, you'd end up re-numbering the issues (or pull requests). Unfortunately GitHub does not distinguish between PRs and Issues in their numbering. So if you create issue number 1, then make a PR, it's number 2. The next issue will be 3, etc. We currently have 4049 issues (1779 open) and 2884 PRs (376 open). One or the other is going to have to be permanently renumbered.

Since we use issue numbers in commit credits, code comments, and API documentation, renumbering the PRs would certainly be less work than renumbering issues.

But as for what's important in the backdrop/backdrop repo: we would need to recreate all 89 releases. However, that could be scripted just like the issue mover.

[ghost]

Since issues are where the main discussion happens then I also think we should keep issues as is, and move the code/PRs.

Does GitHub provide any sort of redirect from old URLs to new? If not, any third-party options for that? We could technically keep the old repo around for that purpose, right?

[ghost]

This conversation came up again in Zulip as a result of having some issues with GitHub actions (triggering based on a PR, but needing to update issues). As a result, I submitted a ticket to GitHub asking for help/advice with this, to know if it's even a possibility. For posterity, here's what I wrote:

---

Backdrop CMS has two main repos:

• https://github.com/backdrop/backdrop: Code and PRs
• https://github.com/backdrop/backdrop-issues/issues: Issues

This was originally done due to GitHub's limited access controls. We needed users to be able to manage issues (open, close, label, etc.) easily, while not necessarily having access to commit/merge code, etc.

Now that things have improved regarding access controls, we're interested in merging the two repos into one so that we can have all code, PRs and issues in the one place. However we're not sure if or how this is possible. Our main concern is that PRs have the same IDs as Issues, and so merging the two would result in URL conflicts, if not other problems.

So we're wondering if you can help us work our how best to do this... The only documentation I could find re. merging repos had to do with keeping commit history, etc., which we need, but that's not the problem. Is there an easy way to combine our two repos into one, without losing any code, history, issues or PRs? Thanks!

[ghost]

GitHub support replied with this:

---

I have looked around, and as it turns out, this is not a feature that is currently offered. I can definitely see a good use case for that functionality too. I am recording this as feedback for our product team to look at for the future. Though we can't say if/when a new feature will be added.

You can also browse our public roadmap to see what we're planning next. We also recommend that you keep an eye on the GitHub Blog for the latest announcements about new features.

Now, let's see if we can get you some information that will with the issue at hand.

As far as the code side of things, you should be able to merge them with the help of something like this gist.

https://gist.github.com/msrose/2feacb303035d11d2d05

For the issues, I found the community post below that has a link in it to something that may work.

https://github.community/t/bulk-transfer-all-issues-to-a-different-repository/1874

The essence of what I gathered from the community post is that you can script out the REST API to loop through the issues and comments in the existing repository and recreate them in the new one with different IDs based on that repositories current ID.