3 ms·

IMHO it's wise to distribute repos to GitLab and also to other hosting solutions beyond just GitHub. One reason is because acquisitions can sometimes be tumult

by jph 8y ago

IMHO it's wise to distribute repos to GitLab and also to other hosting solutions beyond just GitHub. One reason is because acquisitions can sometimes be tumultuous, such as because of employee changes, security changes, alerting changes, etc. A backup git host is prudent.

beager 8y ago
The nature of git itself obviates your case. If Github gets tumultuous, your redundancy is on your local machine and on every machine of your org. Replication of issues, wiki, etc to other hosting providers just sounds like a PITA. If the concern is about Microsoft buying Github and someone gets flighty, I think it’s a little dramatic. Microsoft isn’t about to rock the boat here, neither is Github. Expect marginal, fleeting downtime, marginal pricing changes, and generally higher confidence in GH surviving in the long run.
- Latty 8y ago
  > your redundancy is on your local machine and on every machine of your org *any machine that has pulled recently. There is definitely value in having a mirror that is always live and updating.
- jph 8y ago
  > The nature of git itself obviates your case. My typical case involves more areas. I value having a way for developers to push/pull changes to a well-known agreed-upon place, as well as to read/post/comment on pull requests, tag/branch/integrate for releases, and always-on always-updating availability. Orgs that are my clients do not have default employee machines that are automatically ready to push/pull to each other. This can be because of a range of technical areas e.g. employee machine firewalls, continuous integration server configurations, disk space storage size for large files, etc. This can be because of a range of process areas e.g. a dev team wants to do a git flow that uses pull requests and code review comments, or a legal team wants an audit trail, or a management group wants a dashboard to do updates, etc.
ptman 8y ago
It probably also makes sense to try to backup as much as you can from Github: https://github-backup.branchable.com/ https://github-backup.branchable.com/ Does something like that exist for gitlab?

by jph 8y ago

beager 8y ago

The nature of git itself obviates your case. If Github gets tumultuous, your redundancy is on your local machine and on every machine of your org. Replication of issues, wiki, etc to other hosting providers just sounds like a PITA. If the concern is about Microsoft buying Github and someone gets flighty, I think it’s a little dramatic. Microsoft isn’t about to rock the boat here, neither is Github. Expect marginal, fleeting downtime, marginal pricing changes, and generally higher confidence in GH surviving in the long run.

Latty 8y ago
> your redundancy is on your local machine and on every machine of your org *any machine that has pulled recently. There is definitely value in having a mirror that is always live and updating.
jph 8y ago
> The nature of git itself obviates your case. My typical case involves more areas. I value having a way for developers to push/pull changes to a well-known agreed-upon place, as well as to read/post/comment on pull requests, tag/branch/integrate for releases, and always-on always-updating availability. Orgs that are my clients do not have default employee machines that are automatically ready to push/pull to each other. This can be because of a range of technical areas e.g. employee machine firewalls, continuous integration server configurations, disk space storage size for large files, etc. This can be because of a range of process areas e.g. a dev team wants to do a git flow that uses pull requests and code review comments, or a legal team wants an audit trail, or a management group wants a dashboard to do updates, etc.

ptman 8y ago

It probably also makes sense to try to backup as much as you can from Github: https://github-backup.branchable.com/ https://github-backup.branchable.com/ Does something like that exist for gitlab?