You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Metadata, like pull requests and issues, are not part of a git repo. These features are provided by the platform that hosts your shared git repo. There are tools to migrate metadata from BitBucket, GitLab, Azure DevOps, GitHub Enterprise Server, and github.com. If tools don't exist to migrate the metadata from the platform you are using, your only option is to migrate only the git repo. To migrate a git repo without medatadata, follow the instructions below.
ghstack Stacked diffs and ghstack
Ghstack is a little rough around the edges. It seems to work as advertised, but some of the ways it works are a bit quirky. The following is a list of things I don't like about ghstack:
it creates 3 branches for each commit
PR are from head->base rather than from branch->master
you need force push access to main in order to land a PR
branch protection rules are useless, need to be bypassed by force pushes
This document provides the steps involved in migrating source code from Gerrit to GitHub. The CI/CD setup part is currently out of scope of this document.
Introduction
Below is a guided procedure to ensure a migration from Gerrit to GitHub.
Migration steps
The following steps act as high-level phases when implementing a migration project:
Instructions for migrating a repo from GitHub Enterprise Server to GitHub Enterprise Cloud using `gh gei` with an unsupported blob storage provider or a supported blob storage provider using an unsupported authentication mechanism
These instructions explain how to migrate a repo from GitHub Enterprise Server to GitHub Enterprise Cloud using the gh gei CLI when either:
(a) you want to use an unsupported blob storage provider; or
(b) you want to use a supported blob storage provider with different authentication
The following instructions assume that you have curl and jq installed. There are available for Linux, macOS and Windows Subsystem for Linux (WSL).
Make a note of your GitHub Enterprise Server hostname (e.g. github.acmecorp.com) and expose it as the GHES_HOST environment variable: export GHES_HOST=github.acmecorp.com.
Make a note of the GitHub Enterprise Server organization that owns your origin repo, and expose it as the GHES_ORGANIZATION environment variable: export GHES_ORGANIZATION=engineering.
Make a note of the name of the repo you are migrating in GitHub Enterprise Server, and expose it as the GHES_REPO environment variable: export GHES_REPO=webapp.
By default, windows and mac do not have a case sensitive filesystem. For this reason, I recommend using linux for lfs migration. Also, if the lfs migration seems to take a long time, this is often due to lots of disk I/O. To speed things up, use a cloud linux instance with max disk I/O.
Before migrating to LFS
The first step in migrating to LFS is finding what needs to be migrated. Use git-sizer for this task. Here is a utility script that can be used to run git-sizer on all repos in an org.