LINUX.ORG.RU

Как удобнее держать код в нескольких репах?

 


0

2

Ну, во первых держать всё надо у себя это первое, но на всякий ещё хостить, в идеале на нескольких точках ибо, ибо.

В любом случае всегда есть некая одна внешняя репа которая типа основная, на неё и README опирается и всякое такое прочее. Самый простой вариант, на дополнительной репе создать пустой репозиторий, в текущих проектах прописать например

[remote "all"]
    url = git@gitflic.ru:blogdron/someproject.git
    url = git@github.com:blogdron/someproject.git

сделать

git push -u all master

И всё, теперь каждый git push будет отправлять изменения в два (и более) репозитория. Но, ради эксперимента я взял и удалил первый репозиторий на стороне хостинга, имитируя например его недоступность, вношу изменения и делаю git push

dron@gnu:~/Рабочий-стол/lalala$ git push
fatal: Не удалось прочитать из внешнего репозитория.

Удостоверьтесь, что у вас есть необходимые права доступа
и репозиторий существует.

Ни туда, ни сюда. :( И теперь надо специально отправлять в рабочую репу и/или изменять конфигурацию. Херня какая-то. Как можно игнорировать недоступность репы?

Ещё думалось, зеркалить. Ну, одни дают это делать, другие не дают, херня костыльная короче. Но у всех есть токен API через который можно делать изменения с репозиториями и как вариант написать скрипт, который будет раз в N времени по желанию левой пятки синхронизировать локальные репозитории/включая их создание если их на той стороне нет, с удалёнными отправляя в них изменения. Так каталоги проектов будут чистые и без всякого мусора от разных репозиториев хранения кода, за исключением одного типа основного.

А вы как делаете? Если делаете вообще. У меня сильной надобности нет, скорее спортивный интерес.

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

Как ещё вариант, добавить альяс типа такого

pushall = !git remote | xargs -L1 git push --all

или

pushall = !git remote | xargs -I'{}' git push -u '{}' master

Вот как в альяс дополнительные параметры передать, я не знаю.

JaM
()

Я когда-то для этого пытался заюзать Gitea, которую я и так использую на арендуемом сервере. Там появилась фича зеркалирования на заданные URL.

Но в итоге всё закончилось с просроченным токеном на шитхабе. :)

Так и сижу ручками git push origin master && git push srht master, если конечно не забуду. Gitea вместо пушей делает только pull с того же шитхаба.

a1ba ★★
()

Как писать портянки на makefile так ты первый, а тут подавай готовое.

Можно сделать алиас на две команды средствами баша. Можно алиас средствами самого гита. Можно сделать свою команду. У гита есть механизм когда git hello будет вызывать исполнение файла git-hello. Осталось только положить его в правильное место.

ox55ff ★★★★★
()

Посмотри на это прагматично. Как часто хостинги будут отваливаться, временно? Сколько усилий тебе будет стоить закомментировать строчку в конфиге?

Скорее всего ты тратишь энергию на решение надуманной проблемы.

anonymous
()

только централизованно зеркалировать по крону, иначе рано или поздно окажется, что в разных репах разный порядок и/или количество коммитов. Особенно если разработчиков больше одного.

HE_KOT
()

У меня, например, Open Source-поделки лежат на GitHub, но при этом постоянно зеркалируются в Gitea. Думать не нужно вообще, все делаешь в одной репе, в зеркале подтягиваются все изменения. В случае, если вдруг «GitHub всё», я ничего не потеряю.

Zhbert ★★★★★
()
Ответ на: комментарий от a1ba

Но в итоге всё закончилось с просроченным токеном на шитхабе. :)

Репа приватная, видимо? Открытое он и так отлично вытягивает.

Ну тут же можно просто напоминалку поставить, чтобы не забывать токены обновлять. Всяко удобнее и проще, чем в разные репы пушить.

Zhbert ★★★★★
()

Основной вопрос здесь - не как пушить в несколько реп, а как вообще жить с несколькими полноценными апстримами, в каждый из которых независимо приходят issue и pr, невидимые в другом. По мне так такой сетап сложен в управлении для автора и отнимает значительное время на менеджмент, и сбивает с толку контрибуторов, поэтому такого нужно избегать. Апстрим должен быть один, и если не нравится текущий хостинг - просто переезжай целиком на другой (скорее всего используя родные для целевого хостинга инструменты миграции, что позволит даже номера issue/pr сохранить). Если боишься что он внезапно станет недоступным - делай бэкапы, инструменты есть.

Дополнительно можно, конечно, сделать чисто зеркало кода, запретив issue, pr, wiki, discussions и вообще любую коммуникацию (если платформа такое позволяет, например GH не позволяет запретить PR), но смысла в этом нет, потому что на страницу проекта приходят не за кодом (код достать не проблема сотнями способов), а чтобы оставить фидбек, и read-only страница вызовет только раздражение.

Ещё думалось, зеркалить. Ну, одни дают это делать, другие не дают

Как можно не давать если это обычный push?

anonymous
()
Ответ на: комментарий от Zhbert

Открытое он и так отлично вытягивает

Ты не понял. Пушами за меня занималась Gitea. Чтобы Gitea могла запушить на remote на шитхабе ей нужен пароль. ssh ключ туда вставить нельзя… почему-то? Может я не разобрался.

А так как шитхаб закрыл пуши с паролем по HTTP и вместо этого предлагают истекающие токены, мне просто надоело обновлять токен.

a1ba ★★
()
Ответ на: комментарий от firkax

В том и дело что мелкомягкие жопшники и только избранным дают право сделать автоматически синхронизируемую репу. Даже для Lua не дали, Роберту Иерусалимски вручную иногда делает синхронизацию и то чисто так по приколу, вспомнит сделает, а нет, так нет.

Вот я и хотел бы сидеть у себя локально в локалхосте, держать публично на уютненьком гитфлике, ну и чисто чтобы где то ещё валялись зеркала которые сами синхронизировались, ан нет.

Сейчас склоняюсь к мнению анонимуса, локалхост + 1 публичный апстрим от меня на гитфлике и всё и неча воду баламутить.

Так или иначе у меня локальные репы + их бекап на отдельном диске + копия на гитфлике, я конечно понимаю что мой дерьмокод никому кроме меня не нужен и чего вокруг него трястись, но так мой же, пусть плохенькое зато своё.

А на гитхаб в ридми профиля можно просто ссылок с гитфлика насыпать, ну типа кому надо пройдут да что надо возьмут. Сейчас лично мне гитхаб/гитлаб и прочие нужны только чтобы в чужие апстрими которые там лежат вносить изменения. Ну и форки держать модифицированные, ну короче всё сторонее по сути.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

В том и дело что мелкомягкие жопшники и только избранным дают право сделать автоматически синхронизируемую репу.

Это как? Если пуши запретить то от гита толку не будет, а если не запрещать то как они помешают синхронизации?

firkax ★★★★★
()
Ответ на: комментарий от firkax

Это как?

Это когда ты избранный и можешь нажать создать репу, указать что эту репу нужно выкачать из другой по ссылке и поставить галочку забирать изменения автоматически и всё, появляется у тебя репа га гитхабе которая раз в период времени сама забирает изменения по ссылке что ты указал ранее и применяет их к текущей репе. Чисто зеркало получается. То есть с твоей стороны больше делать вообще ничего не надо будет. Раньше можно было такое, а теперь только по запросу или платной подписке.

Смысл в том что ты пушишь себе в тихий и уютный сервак, а зеркало там само зеркалит тебя и вы друг друга не касаетесь.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от Zhbert

Ты говоришь про вариант, когда в github основная репа, а self-hosted gitea берёт себе копию. Я так делаю с чужими репами, исходники которых хочу иметь у себя.

А вот когда нужно наоборот, надо таки следить за токеном. Впрочем, это автоматизируется и gitea мне напишет, если вдруг что протухнет.

shell-script ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Не вижу чем эта схема лучше пушей со своей стороны. Наоборот, она хуже практически во всём. И гитхабу (надо лишние действия со своей стороны по расписанию делать и хуже того лезть в чужие сервера), и тебе (чтоб гитхаб смог забрать - надо иметь фиксированный и доступный адрес в интернете, а так же приходится получать спам от этих проверок «а не появилось ли что нового»). Вобщем, мне бы и в голову не пришло реализовывать эту схему при наличии возможности самостоятельно слать пуши когда надо.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Наоборот, она хуже практически во всём. И гитхабу (надо лишние действия со своей стороны по расписанию делать и хуже того лезть в чужие сервера)

Чёйта, это классическая схема зеркалирования, так все зеркала репозиториев линукса работают, одно главное, а остальные просто с него подтягивают изменения. При этом зеркало это просто зеркало и ничего более. Что там удобно или не удобно гитхабу это вообще по барабану, раз в час им на своей стороне сделать git pull не проблема, просто это их бизнес модель, хочешь вот так, без проблем оплати годовую (или как там подписку).

Самостоятельные пуши это да… ой короче, гит сам по себе хоть и даёт удобства в плане ну вот я вижу что у меня было раньше, но и добавляет кучу гемороя когда нужно тупо закинуть куда-то 5 килобайт кода, чтобы он тупо валялся ещё где-то.

Ладно, так или иначе интерес больше как я сказал спортивный, узнать как у людей, я обычно сначала сам нахимичу, а лишь потом узнаю как люди делают, тут решил узнать заранее =) Вдруг захочется сильно или будет нужно.

Подытожу, зеркала я имею в виду просто как зеркала. Как репы с deb пакетами. Вот и всё.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

Если зеркало это кто-то посторонний кто хочет за тобой следить то да, других вариантов не остаётся. Но это тот, кто хочет следить, тратит свои ресурсы на достижение желаемого. А если это ты сам хочешь зеркалить свою репу куда-то то, очевидно, логично тебе самом это и инициировать пушами.

Не вижу в чём тут может быть вообще проблема.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от anonymous

Основной вопрос здесь - не как пушить в несколько реп, а как вообще жить с несколькими полноценными апстримами, в каждый из которых независимо приходят issue и pr, невидимые в другом

Элементарно. Либо отключить их везде, кроме одного из мест, либо сделать удобно своим пользователям и принимать их везде, где удобно для них.

Вообще, привязка багтрекера к репозиторию это форменная дичь, лучше поднять отдельный полноценный багтрекер вместо использования этих убогих зумерских поделок.

annulen ★★★★★
()
Ответ на: комментарий от annulen

Вообще, привязка багтрекера к репозиторию это форменная дичь, лучше поднять отдельный полноценный багтрекер вместо использования этих убогих зумерских поделок.

Для начала, Костя, убери подальше свой эйжизм, он твоему мнению ценности не прибавляет. Потом, зумеры составляют больше половины современного СПО сообщества, и логично учитывать их интересы. После этого подумай ещё раз над своим опусом. Во-первых, самый банальный и очевидный факт состоит в том что issue напрямую связаны с PR, и форменная дичь, разделять их по разным системам. А уносить PR от репозитория, я надеюсь, даже тебе в голову не придёт. Во-вторых, для тех кто контрибутит более чем в один проект трекинг своих issue по куче размазанных по всему интернету трекерах банально невозможен. На GitHub заходят каждый день и сразу видят что что в issue в проект X попросили предоставить дополнительной информации. На неюзабельный trac проекта Y, даже если потратят время на регистрацию в нём (не потратят), посмотреть статус своего issue и что-то туда добавить не вернутся никогда. В-третьих, многие считают базу issue чуть ли не равноценной коду по значимости для развития проекта, а судьба селфхостед трекера - умереть вместе со всей базой когда оригинальный автор потеряет интерес к проекту. На GitHub же всё останется рядом с кодом.

В итоге и зумеры, и миллениалы вроде нас не просто предпочитают, но считают единственным рабочим решением вести issue вместе с кодом.

anonymous
()
Ответ на: комментарий от anonymous

Не в идеале да, держать всё поближе. Но не стоит забывать что порой регистрация где-то для того чтобы сказать «дядя тут кнопочка вот не нажимается уменя когда я делаю вот так, почини пожажа гыыыы» может стать фатальной, по хорошему по мимо этих всех иссуе и прочих нужна тупая форма обратной связи со спам фильтром. Так что есть смысл и удобство для всех когда всё в одном и всё понятно, не надо никуда прыгать, но и удобство в множестве точек взаимодействия тоже есть, просто эти удобства для разных людей. Вы правы оба одновременно и не правы в своей категоричности в отношении своего выбора и только его, тоже оба. :)

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Так что есть смысл и удобство для всех когда всё в одном и всё понятно, не надо никуда прыгать, но и удобство в множестве точек взаимодействия тоже есть, просто эти удобства для разных людей

Какие удобства и для каких людей в том что issue будут лежать отдельно от кода, никак не интегрироваться ни с какими workflow связанными с кодом включая PR, и требовать отдельной регистрации? Давайте только договоримся тех кто делит людей на касты по признаку рождения до 1993 года и одну из этих каст считает неполноценной и всё что ими сделанное забракованным (при том что github’овский трекер был написан таки другой кастой), за людей не считать.

Вы правы оба одновременно и не правы в своей категоричности в отношении своего выбора и только его, тоже оба. :)

Я ни слова не сказал про свой выбор. Это выбор сообщества, иначе бы местячковые трекеры использовались повсеместно.

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

Раньше можно было такое, а теперь только по запросу или платной подписке.

Сейчас это элементарно делается на actions. Их можно запускать периодически и их них можно пушить в реп.

anonymous
()
Ответ на: комментарий от anonymous

Ты слишком далеко залез, всё гораздо проще. Когда всё в 1 месте всё просто всем понятнее со всеми вытекающими плюсами и минусами, когда репа лежит в А, а сообщить о проблеме можно в Б,В,Г,Д и Е, то так удобнее например индусу который кое как зарегался на гитхабе, а у тебя репа лежит на мосхабе и для него будет титаническая проблема написать тебе сообщение об ошибке так как у него нет SberID :D, смысл в том что если у человека нет возможности написать там где он привык то он вообще ничего не напишет скорее всего и

issue будут лежать отдельно от кода

Они не будут лежать, их не будет вообще (не вообще всех не будет, а тех которые могли бы быть) и у этого свои минусы и плюсы, я вот про это говорил.

Ты просто сам выбираешь как автор держать всё в 1 месте, и в этом нет проблем например так Lua делает и всем норм, tar.gz для кода и список рассылки для всего остального, или размазываться где только можно, так SDL2/3 сейчас делает у них и форум и сайт свой, и почтовая рассылка и гитаб, тучи точек соприкосновения. И оба правы и обоим норм. Вот и всё. Тут нет никаких тайных смыслов или двоякочтения, тупо личная практичность и личное удобство. Вот и сё

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

когда репа лежит в А, а сообщить о проблеме можно в Б,В,Г,Д и Е, то так удобнее например индусу который кое как зарегался на гитхабе, а у тебя репа лежит на мосхабе

Так просто не надо пользоваться никакими мосхабами, а надо пользоваться гитхабом, который доступен и тебе и любому индусу.

Они не будут лежать, их не будет вообще (не вообще всех не будет, а тех которые могли бы быть) и у этого свои минусы и плюсы, я вот про это говорил

Ещё раз, какие конкретно нахрен плюсы у того что issue которые могли бы быть не будет?

anonymous
()
Ответ на: комментарий от anonymous

а надо пользоваться гитхабом

Опционально, тут слово «надо» лишнее. Он есть, ну и хорошо, есть много чего ещё и другого.

который доступен и тебе и любому индусу.

Нет, он доступен не всем конечно, далеко не всем.

Ещё раз, какие конкретно нахрен плюсы у того что issue которые могли бы быть не будет?

Это не плюс, а минус, я говорил о двух противоположностях о полной централизации апстрима и частичной, при полной ты гарантированно теряешь часть обратной связи, при частичной ты теряешь удобство централизации. Всё.

Ладно, в общих вопросах разобрались, в остальном у каждого свои мнения.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Основной вопрос здесь - не как пушить в несколько реп, а как вообще жить с несколькими полноценными апстримами, в каждый из которых независимо приходят issue и pr, невидимые в другом.

Вот это как раз легко: вырубаешь issue и pr во всех кроме основного.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

Никто не обязан пользоваться продукцией компании microsoft.

Совершенно верно, равно как и никто не обязан пользоваться self-hosted сервисами всяких васянов.

anonymous
()
Ответ на: комментарий от LINUX-ORG-RU

Опционально, тут слово «надо» лишнее. Он есть, ну и хорошо, есть много чего ещё и другого.

Нет, «надо» тут - обязательное и основное слово. Самым популярным хостингом кода нельзя не пользоваться если ты хочешь быть частью сообщества. Писать в стол свои поделки, не пользоваться чужим кодом, никуда не контрибутить, ничего не публиковать, не иметь контрибуторов и пользователей - можно и на локалхосте, и на self-hosted, и на гитфлике. Но не надо путать это с участием в FOSS и FOSS разработкой. Для неё github обязателен.

Нет, он доступен не всем конечно, далеко не всем.

Если собрался придираться к словам то пусть не всем, но он на порядок доступнее чем любой другой хостинг.

anonymous
()
Ответ на: комментарий от anonymous

Не везде это возможно, например на GH нельзя вырубить PR.

Да и срать. Ставишь бота, который автоматом их все закрывает сразу же, и не паришься. Если чувак – дебил и не может прочитать в README что это зеркало, то вряд ли от него что-то хорошее прилетит.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

Нет, «надо» тут - обязательное и основное слово. Самым популярным хостингом кода нельзя не пользоваться если ты хочешь быть частью сообщества. Писать в стол свои поделки, не пользоваться чужим кодом, никуда не контрибутить, ничего не публиковать, не иметь контрибуторов и пользователей - можно и на локалхосте, и на self-hosted, и на гитфлике. Но не надо путать это с участием в FOSS и FOSS разработкой. Для неё github обязателен.

Ваще легко. У крупных опенсорсных проектов свои сервера в любом случае. На гитхабе только всякая мелочь хостится.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Zhbert

токены зло, использовать ssh + ключи просто и удобно, но почему все пароли и токены юзают, я наверно идиот чегото не знаю не понимаю

s-warus ★★★
()
Последнее исправление: s-warus (всего исправлений: 1)
Ответ на: комментарий от s-warus

токены зло, использовать ssh + ключи просто и удобно, но почему все пароли и токены юзают, я наверно идиот чегото не знаю не понимаю

Потому что гитхаб насильно заставляет это делать. Например, чтобы скачать бинарик из CI приватного репозитария на жидхабе, нужен токен и, если память не изменяет, два или три запроса курлом. Они там вообще чудовищного говна наворотили, это одна из причин почему я на жидхабе только зеркала своего кода держу.

hateyoufeel ★★★★★
()
Ответ на: комментарий от Zhbert

А оригинал где-то в открытом доступе есть?

Да.

Как быть, если, например, на гитхабе тебе принесут ишью или даже пулреквест?

Issue не принесут, они выключены. PR будет закрыт автоматически с комментом о том, куда его надо отправить.

https://github.com/superbrothers/close-pull-request

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)

Ну, во первых держать всё надо у себя это первое, но на всякий ещё хостить, в идеале на нескольких точках ибо, ибо.

Люди отучились думать и затыкаются на простейших вещей. Git это система контроля версий, а не бэкап. Развертывать множественные активные отдельные git-репозитории в цели бэкапа («на нескольких точках ибо, ибо») это натягивать сову на глобус.

Backing up a Git repository with the Git CLI

A Git repository includes all of the files and folders associated with a project, along with each file’s revision history.

You can take a backup of a Git repository, including the revision history, by performing a mirror clone with the Git CLI.

To perform a mirror clone, use the git clone command with the –mirror option.

git clone --mirror https://github.com/EXAMPLE-USER/REPOSITORY.git

If the repository includes Git Large File Storage objects, pull in the objects. For more details on Git Large File Storage and how to install it, see «About Git Large File Storage.»

git lfs fetch --all

Once you have cloned the Git repository, you can compress it into an archive (for example a .zip or .tar.gz file) and move it to a location for safe-keeping.

You can restore your backup by decompressing the archive and then pushing the Git repository to a Git remote.

manul91
()
Ответ на: комментарий от hateyoufeel

runs-on: ubuntu-latest

Епрст.

Для того, чтобы выполнить действие по факту прилетевшего пуллреквеста, поднимается контейнер с бубунтой. И ЖС!

До чего дошел регресс.

token_polyak ★★★★★
()
Ответ на: комментарий от token_polyak

Для того, чтобы выполнить действие по факту прилетевшего пуллреквеста, поднимается контейнер с бубунтой. И ЖС!

Да и посрать? Ну то есть, ты можешь лично сходить и переделать это в запрос через curl, если тебе хочется. Но пока это не мои лично мощности, а бесплатное говно от жидхаба, я не против лишний раз нагрузить сервера Microsoft. Особенно бесплатно.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Да и срать. Ставишь бота, который автоматом их все закрывает сразу же, и не паришься. Если чувак – дебил и не может прочитать в README что это зеркало, то вряд ли от него что-то хорошее прилетит.

Ну тут уже всем становится понятно что дебил - автор репозитория и не стоит в него ничего контрибутить.

Ваще легко. У крупных опенсорсных проектов свои сервера в любом случае. На гитхабе только всякая мелочь хостится.

Даже со своими серверами нормальные проекты взаимодействие с сообществом строят именно через GH. Из недавнего крупного на гитхабовские issues перешёл, например, питон.

anonymous
()
Ответ на: комментарий от anonymous

Даже со своими серверами нормальные проекты взаимодействие с сообществом строят именно через GH. Из недавнего крупного на гитхабовские issues перешёл, например, питон.

Практически весь основной линуксовый софт никогда на гитхабе не был, если не считать зеркал. Ядро, glibc, gcc, KDE, GNOME, весь freedesktop.org. Им всем на твой гитхаб срать.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)