Move repositories on GitHub without breaking links to PRs

 Since it took me way too much time to figure this out, I'll write it down for future references.

I needed to move a git repository from one GitHub repository to another one that already had code, past PRs, etc. It wasn't a simple rename which would make GitHub redirect everything. It was adding a new history from one repository to another, while not getting rid of the past tags, releases.

When you squash a PR on GitHub by default it'll write the commit message (#1)

Where the number following the # character is the PR number. When viewing this message on GitHub it'll link to the PR page on the repo.

If you simply push that git repo to another github repository, it'll link to the wrong PR page.

To fix that you need to rename the #1 to a fully qualified PR link that GitHub understands.

It has the format: organization/repository#1

 

For that, I've used a tool called git-filter-repo.

 

git filter-repo --commit-callback '
message = commit.message
new_msg = re.sub(br"(#(\d*))", br"org/repo\1", message, flags=re.MULTILINE)
print(new_msg)
commit.message = new_msg
' --refs HEAD

On the target repository I created an orphan branch:

git checkout --orphan main

Pull the rewritten repository into main branch, and pushed to remote. That's it.

Swift adventures: CocoaLumberjack logger

I haven't had much contact with Swift other than writing a few unit tests on a project. So when someone asked about sending CocoaLumberjack logs to Sentry on the forum I thought it was a good excuse to write some Swift on the weekend.

To create an integration between two libraries written in Objective-C, to make sure you can support the most number of apps and platforms, the choice for a language is obvious: Objective-C.

The best thing about such a hobby project is:

Making sure you can support old code bases, where the developers have not invested in keeping things up-to-date doesn't not become a priority to you.

 

With that in mind, I went ahead with the latest stable Swift version: 5.2.

 

At the start I learned that I actually don't need xcode at all. So as part of my experiment, I decided to go without any of those xcworkspace, pbxproj, xcscheme etc, and use only Visual Studio Code.

And the Swift CLI:

 

swift build

and

swift run

 

With the right Visual Studio tasks and launch configuration I was even able to step through the code with the debugger. Generally really nice.

In the process I also learned about the Swift Package Index which builds your project with different Swift versions and targets and creates a badge describing the compatibility.

 

On top of all the fun learning a new language and ecosystem, I got a good reminder that dogfooding is an incredible tool. Specially when you're building APIs and SDKs. I would even say that it makes sense to have a project at work that the team could work together a few hours a week to get a good verification of the experience of using what you're building.

The code is here if you're interested: https://github.com/bruno-garcia/SentryCocoaLumberjack

The low res gif I recorded: