Що станеться, якщо сховище залежності буде видалено на GitHub?

Я маю сховище GitHub, А.
Репозиторій B - ще один проект з відкритим кодом, яким належить хтось інший.
Репозиторій A залежить від сховища B (сховище B - підмодуль A).

Якщо власник сховища B вирішить видалити це сховище, користувачі більше не зможуть успішно клонувати / оформляти / складати моє сховище.

Чи слід попередньо форк B використовувати як резервну копію, якщо власник вирішив його видалити? Чи вважається це небезпечною ситуацією, або як це зазвичай вирішується для проектів з відкритим джерелом?

open-source version-control github

Виправте мене, якщо я щось пропускаю, але якщо A залежить від B, тоді, коли хтось хоче побудувати A, він повинен клонувати і A, і B, тому навіть якщо B видалили, кожен, хто використовує A, мабуть, має копію B (включаючи історію) лежить навколо їхньої системи, оскільки git - це DVCS, тому шанси на те, що ви можете створити вилку заднім числом. Правильно? Або це якась інша «залежність»?

Це нормальна субрепо залежність. Але в основному я підтримую A. Це стабільно, і не відбувається активної розробки (лише періодичні виправлення), тому для того, щоб зберегти чисту малу SSD, я зберігаю лише код на GitHub. Тому я відчуваю, що це небезпечна ситуація, оскільки А буде мати проблеми, якщо власник В коли-небудь вирішить видалити В, а у мене немає вигідної вилки.

Вилки безкоштовні. Якщо це допомагає вам спати вночі, зробіть це.

Якщо власник сховища B вирішить видалити це сховище, користувачі більше не зможуть успішно клонувати / оформляти / складати моє сховище.

Якщо залежний код "repo B" зникає:

Усі користувачі зможуть успішно клонувати ваше репо.
Існуючі користувачі, мабуть, матимуть копію репо B на місцевому рівні та продовжуватимуть створення просто. Клоновані репозиції, як правило, не видаляються, якщо джерело видалено, якщо користувач не вийшов зі шляху, щоб спеціально налаштуватись на цей сценарій. Оскільки Git - це DVCS, він створений для захисту від подібних речей.
Нові користувачі не зможуть створити ваше репо, поки вони не зможуть звідкись отримати копію репо B. Ви б були в цьому човні, оскільки не зберігаєте резервну копію.

Чи слід попередньо форк B використовувати як резервну копію, якщо власник вирішив його видалити?

Так.

Чи вважається це небезпечною ситуацією або як це зазвичай вирішується для проектів з відкритим джерелом?

Так, це може бути небезпечна ситуація, залежно від популярності / розповсюдження / дзеркал залежного репо та того, наскільки важливе для вас репо. Якщо це важливо для інших, вони (сподіваємось) вже мають резервну копію як вашої репо, так і dep repo.

Зауважте, що ви можете передати його на GitHub до свого облікового запису, а не клонувати його на свій SSD, щоб не зайняти місце. Крім того, майте на увазі, що цей параметр резервного копіювання залежить від того, що з серверами GitHub нічого не відбувається або ваш рахунок не буде порушений; тільки ви можете визначити ступінь надмірності, який є адекватним.

Розгляньте кількість коду, на який ви покладаєтесь, його популярність, складність відтворення та вартість надійного зберігання. Розглянувши цю оцінку ризику, створіть її відповідно.

Оскільки вартість здається фактором вашої ситуації, враховуючи, що ви не хочете витрачати більше на більшу кількість SSD, ось список дешевих варіантів резервного копіювання:

Очевидно, роздрібніть його на GitHub, оскільки він повністю безкоштовний. GitHub використовуватиме дедуплікацію, тому вартість для них надзвичайно мінімальна.
Місцеві (безкоштовно), старі спінінг-накопичувачі або флешки. Крім того, ви вже можете платити за безкоштовне резервне копіювання хмар через ваш Інтернет-провайдер або мобільний оператор.
Віддалено (безкоштовно) безліч варіантів резервного копіювання хмари або попросити друга.
Придбайте віддалено ($) за план Usenet за ГБ і завантажте його на Usenet (~ 25 Гб за 10 дол. США)

— адам
джерело