4 ms·
Your instructions would only apply to a dead repo. Migrating an active repo is going to require coordination, dry runs, validation, and planning coupled with up
by bastardoperator 4y ago
Your instructions would only apply to a dead repo. Migrating an active repo is going to require coordination, dry runs, validation, and planning coupled with updates across your integrations. If you rewrite any history, all bets are off. You're also not taking into account any cleanup activities like reflog expire, or gc prune.
I would also argue that moving to a self hosted remote is going to have significant administrative burden when it comes to security and updates compared to anything SaaS.
Most people use GitHub, GitLab, and Bitbucket for the collaboration features, everyone already knows they can run vanilla git and actively choose not to.
- nottorp 4y ago> updates across your integrations That's already vendor lock in - you're using GitHub's CI pipeline? You're locked.
- bastardoperator 4y agoIf I have to update my Jenkins server because I moved from one Git provider to another, I have to point my existing integrations to my new git provider. That's the opposite of being locked in, and just a fact of the matter.
- nottorp 4y agoThat sounds like it's your Jenkins server not GitHub's.
- bastardoperator 4y agoYes, it's an integration the repo and users rely on. Any integration that is using a specific git URI will need to be updated. This means new keys, access tokens, and configurations within the integration will need to be updated. That's not a simple process.