GCLI 2.10.0

теперь использует Perl

Давно пора.

atf-c

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

Почему гуглится масло, а не утилита, вопросы к маркетологам.

не знаю, не знаю.Мне нравится давно,давно Cgit.Сложно превыкать к новому и изведанному.

А мне арахис нравится больше, чем экскаватор. Тоже давно.

я про то, что часто менять партнеров опасно для здоровья :-)

А зачем оно нужно? Промежуточное апи, чтобы что? Кто-то будет делать общий фронтенд, довольно хрупкий из-за доп. звена? Автоматизация каких-то действий, но почему не через родное апи? Кому нужен один интерфейс для пачки git-хостингов?

да это это технически не правильно.Компании используют к примеру ядро один cgit и к примеру qt.io. Они не станут использовать подобную тактику.

чтобы что?

Чтоб браузер пореже запускать.

Например, тем, кто зеркалит проект на разных хостингах, нет?

// На клавиатуре мобильника поначалу вместо «зеркалит» набралось «херкадит».

Например, тем, кто зеркалит проект на разных хостингах, нет?

Я, конечно, в жизни на разное насмотрелся, но зачем?

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

Чтоб браузер пореже запускать.

Чтобы что? Или такая нелюбовь к вебной гуйне, что берётся тулза, которая может ещё и не весь объём функционала покрывать. Как будто если что-то заскриптовать нужно, то лучше взять напрямую апи своего хостинга. Одни и те же скрипты для разных хостингов... выглядит сомнительно.

Например, тем, кто зеркалит проект на разных хостингах, нет?

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

Единственное, что мне пришло в голову, так то, что эта утилита может помочь с миграцией с одного хостинга на другой, но и это сомнительно.

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

Так популярные хостинги уже сами давно зеркалирование между собой наладили. Зачем для этого «третий лишний»?

Или такая нелюбовь к вебной гуйне

Да!

Чтоб браузер пореже запускать.

Чтобы что?

Потому что.

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

Внезапно, утилита и использует API, предоставляемые хостингами, напрямую.
Для чего же ещё, тот же GitHub, предоставляет свои данные и в GraphQL и в JSON?
Именно что для подобных сторонних утилит и скриптов.

Зачем париться с поддержкой разных хостингов?

Аж три человека недоумевают, зачем это надо. Ну например, у меня проект на гитхабе, и я на случай полной и окончательной победы чебурнета (к которому, напоминаю, пихают с обеих сторон) хочу иметь зеркало на каком-нибудь гитфлике. Я действительно чего-то странного хочу? gns, это и к тебе вопрос.

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

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

гит не умеет клонировать репозиторий из двух мест.

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

Кому нужен один интерфейс для пачки git-хостингов?

например всем тем, у кого на работе приватный инстанс гитлаба, но и в опенсорс на гитхабе тоже хочется тыкать. По-моему очень распространенный сценарий.

К сожалению, очень просто запутаться куда что отправил. Хотя может это только у меня с гитом дружба не сложилась. Я много систем контроля версий за жизнь перепользовал, так вот только гита до сих пор боюсь.

Инструменты-то есть, удобства не особо много.

Думаю, самоконтроль плюс какие-то ad-hoc автоматизации, чтобы предотвращали неаккуратное использование. Мой прогноз: на хуках можно соорудить приемлемое решение для того, чтобы не отправить лишнего, куда не следует.

В целом, оно довольно просто внутри устроено, по крайней мере, на том уровне, который нужен для решения задач, касающихся управления бранчами и тегами и взаимодействия с удалёнными репозиториями. Вдумчивое разглядывание .git/config, .git/packed-refs и .git/refs/ позволяет понять, как устроена система объектных меток.

Но, конечно, от задачи надо плясать.

А как тут помогает эта тулза? Зачем вам в этом случае общий cli к внутреннему хосту и к гитхабу? Скриптами что-нибудь к редмайну, например, прикручивать?

Немного вымораживает то, что гит позволяет иметь ветки с одним именем, но с разных источников. А если они еще и не связаны друг с другом, то никогда не поймешь, с какой веткой issue666 ты сейчас работаешь и с какого круга ада ты ее себе запуллил :)

" Это не баг, это фича!.." © ;))

Скорее артефакт распределенных систем контроля версий. Используй git в режиме subversion с одним корпоративным репозиторием и будет тебе счастье :)

Используй git в режиме subversion с одним корпоративным репозиторием и будет тебе счастье :)

Мне уже давно счастье: я не использую всё это merde...:))

Я б тоже не использовал, но, панимаш, работа такая... Какой станок дали, на том детали и точи :)

Чтоб браузер пореже запускать.

Чтобы что?

чтобы в termux работало?

Я б тоже не использовал, но, панимаш, работа такая... Какой станок дали, на том детали и точи :)

Панимяу. Сочувствую. :))

Мне проще: я сам выбираю «станок»... ;))