| |
| 2.4, Аркагоблин (?), 12:41, 21/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Можно подумать есть выбор. GitHub, GitLab, даже Codeberg - всё заточено на Git. Да, можно найти маргинальный сервис с чем-то другим, но если у кода не появится пользователей (а там их точно не появится!), то зачем тогда публиковать?
| | |
| |
| 3.21, Аноним (21), 14:11, 21/04/2026 [^] [^^] [^^^] [ответить]
| +3 +/– |
Не понял смысл твоего мутного высера. Лично где ты был когда игнорировали Mercurial?
| | |
| 3.38, Аноним (38), 15:23, 21/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для альтернативно одарённых есть новодельные vcs совместимые с гитовым хранилищем, например jj. Попробуйте, расскажете.
| | |
| 3.41, Аноним (41), 15:28, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>GitLab, даже Codeberg - всё заточено на Git
Нужен либо аналог, либо поддержка в одном из.
>то зачем тогда публиковать?
Поднимайте зеркало, и публикуйте и там и там, в чём проблема?
| | |
| |
| 4.48, Аркагоблин (?), 16:10, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
А зачем мне публиковать и там и там? Только ради другой СКВ, чтобы показать "что у меня не git"? Нет, спасибо
| | |
|
| 3.56, Аноним (-), 17:01, 21/04/2026 [^] [^^] [^^^] [ответить] | –2 +/– | Ну так был sourceforge, тормозил с гитом по упора, сватая отличные CVS и SVN -... большой текст свёрнут, показать | | |
| |
| 4.77, Аноним (77), 18:45, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>SVN
Особенно потрясающе там теги и субмодули были сделаны, с которыми никогда не знаешь, в какую репу коммитишь.
| | |
|
| 3.98, OpenEcho (?), 23:57, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Можно подумать есть выбор.
Ну вон sqlite вполне себе обходится fossil-scm, который по ходу all-in-one и трекер и форум и вики и SCM и всё в одном флаконе, а с "миром" (с гитом т.е.) через импорт/экспорт
| | |
|
| 2.5, Аноним (5), 12:43, 21/04/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>Лучшая система контроля версий ever.
Нету конкурентов. BitKeeper послал ядро и Линуса, ядро и Линус послало биткипера, так появился гит.
| | |
| |
| |
| 4.57, Аноним (-), 17:02, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Юникс послал гну и ядро и так появился Линукс.
Наоборот. Но суть в целом не меняет.
| | |
|
| 3.29, Аноним (38), 14:44, 21/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ой, конкурентов навалом было - инвалидный hg, маргинальные фоссилы и пихули, математичный darcs ажно основанный на patch theory. История рассудила.
| | |
|
| |
| 3.58, Аноним (-), 17:13, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> ... называется hg.
Месиво на питоне который нетормозит (так что каждую версию рассказывали на сколько именно неторможение улучшено). И который отлично совместим между версиями. Но правда к моменту дропа версии 2 - коса нашла на камень и столько кода переписать до потери актуальности господа просто не смогли нормально.
| | |
|
| 2.78, ptr (ok), 18:51, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Смотря для чего. Если именно для текстов - да. Если же есть необходимость в системе контроля версий для бинарных данных, то нет. C этим SVN справляется намного лучше.
| | |
| |
| 3.84, Аноним (38), 19:44, 21/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> C этим SVN справляется намного лучше.
И в чём лучшесть? Гиту, на самом деле, вообще по барабану какие данные трекать - с блобами он справляется также как с текстом, с большими блобами так же как с маленькими.
Когда говорят о бинарных данных, обычно имеют в виду что не хотят хранить всю их историю локально. Для этого есть LFS, другой инструмент тащить совершенно не обязательно. Тем более SVN, который "лучше" не справляется вообще ни с чем.
| | |
| |
| 4.96, ptr (ok), 23:24, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
>> C этим SVN справляется намного лучше.
> И в чём лучшесть?
Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком.
> Гиту, на самом деле, вообще по барабану какие
> данные трекать - с блобами он справляется также как с текстом,
> с большими блобами так же как с маленькими.
А Вы проверьте. Возьмите видеоролик размером хотя бы в несколько десятков мегабайт, наложите титры названия на начало, чтобы нужно перекодировать всего один-два фрейма от ключевого кадра до ключевого. Затем десять раз поправьте текст, шрифт или местоположение этих титров, делая после каждой корректировки commit. В результате репозиторий Git окажется почти на порядок большего размера, чем у SVN.
> Когда говорят о бинарных данных, обычно имеют в виду что не хотят
> хранить всю их историю локально.
Откуда такие экстрасенсорные провидения?
> Для этого есть LFS
И как же она заменит систему контроля версий?
| | |
|
|
|
| 1.6, Sm0ke85 (ok), 12:43, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>Выпуск системы управления исходными текстами Git 2.54
Заголовок не точный...
'''
Git — распределённая система управления Версиями.
'''
| | |
| 1.7, Аркагоблин (?), 12:48, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.
| | |
| |
| 2.14, Аноним (1), 13:36, 21/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Мне плевать на монополию и какие-то там приложения, которые её используют (кстати, что это за приложения?). Я оцениваю по объективным признакам - она просто самая лучшая из тех, что существуют или когда-либо существовали: rcs, cvs, svn, fossil, hg
| | |
| |
| 3.15, Аркагоблин (?), 13:50, 21/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Объективным качествам? Так древнеарамейский язык может тоже качественный, но если на нём не с кем общаться и его нельзя применить на практике, то и его качество бесполезно.
| | |
|
| 2.16, Аноним (16), 13:56, 21/04/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
Она не лучшая СКВ, но монополий там, где действуют сетевые эффекты, избежать невозможно. А в СКВ они особенно сильны. Просто все проприетарщики кроме гитхаба оказались клиническими д********и и просрали все полимеры.
| | |
| |
| 3.34, Аноним (38), 14:57, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Конечно плохо, это же в первом классе рассказывают. Безусловно нужно демонополизировать и пользоваться 2-3 несовместимыми VCS.
| | |
| 3.79, Аноним (79), 18:57, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Монополия в it-технологиях это какой-то оксюморон. Хотите - откапывайте для себя битбакеты, Линус со своим гитом вам не помешает.
| | |
|
| 2.31, Аноним (38), 14:50, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.
Ну да, а монополией её сделал лично Линус, потому что ходил по домам разработчиком и сносил им другие VCS. Нет, она монополия именно потому что лучшая. У hg были все шансы, он не взлетел. У большинства VCS-новоделов есть интероп с гитом, поэтому тоже все шансы, но кто ими пользуется?
| | |
| |
| |
| 4.74, Аноним (74), 18:17, 21/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
При десятке аналогов упирающихся в корявость альтернатив.
github и стал популярен из-за заточенности на git в отличии от других.
| | |
| |
| 5.87, Аноним (87), 21:37, 21/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Наоборот, GitHub оказался просто ПЕРВОЙ единственной серьёзно, нормально, с душой, слепленной социалочкой для кодеров, без лишней email-<предъявите ваш телефон и паспорт>-идиотии, а не наколеночным поделием, как остальные. Ну а что в GitHubе было - то и взлетело. Сам гитхаб прибил конкурентов за счёт тех же сетевых эффектов. В некоторые годы GitLab были намного лучше, но потом тоже хренеть начали, когда базу набирали.
| | |
| |
| 6.94, Аноним83 (?), 22:15, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
GitLab - фигня какая то запутанная, тормозная и перегруженная - никогда там ничего что надо не найти.
| | |
|
|
|
|
|
| |
| |
| 3.18, Аноним83 (?), 14:04, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Потому что у меня набор локальных патчей, и я периодически подтягиваю с апстрима свежее и мне надо чтобы мои коммиты накатились сверху.
В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно.
В моём представлении там всего то надо вызывать patch, потом git add, git commit. Учитывая что оно делается внутри одного бинарника то я ожидаю что с моми диффами в 1кб оно должно работать непрелично быстро.
| | |
| |
| 4.32, Аноним (38), 14:53, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Тоже такое замечал на дереве портов FreeBSD (хотя это огромный реп). Стоило бы это попрофайлить, но пока недостаточно чешется.
| | |
| 4.35, Аноним (41), 15:07, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно.
Помещаете в переменные $from указатель на последний коммит из родительской ветки, $to - последний нужный вам коммит, это можно автоматизировать, опираясь на ваш подход, после чего делаете
git diff "$from..$to" | git apply
git add .
git commit -m 'one commit'
Данная команда сожмёт всё в один коммит. Можно расписать более сложную логику, например через git log --name-only получать список имён, но это уже делать вам.
| | |
|
| |
| 4.52, Аноним83 (?), 16:40, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Нет.
git -C /usr/ports/ pull --rebase upstream main
git -C /usr/ports/ push -f origin main
| | |
| |
| |
| 6.63, Аноним (63), 17:37, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Ужасно
Они там в BSD - CVS и SVN покусаны и поэтому напрочь не одупляют как работает git.
Они и реплеят ударными темпами 100500 комитов на свое счастье. Внятно оформить свое счастье и ребэйзнуть на что-то более новое? Не, вы что, это слишком просто. Вот елси профайинг вместо этого затеять...
| | |
|
|
|
|
| 2.59, Аноним (-), 17:16, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> У меня rebase всегда какой то медленный, вот бы его ускорили.
А что ты с ним делаешь чтобы он был медленный? Реплеишь 100500 комитов? Ну так отребэйзь свои чудо-патчи на что-нибудь более новое - быстрее будет. Потому что меньше комитов реплеить.
| | |
| |
| 3.80, Аноним83 (?), 18:57, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Я выше написал как я делаю.
Что вы предлагаете?
Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану.
| | |
|
|
| 1.23, RM (ok), 14:24, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
git rip?
из текста новости
Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите,
и ниже
Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений
| | |
| |
| 2.33, Аноним (38), 14:54, 21/04/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ох. Тебе рассказать чем отличается локальная история от публичной? Не, иди сам почитай.
| | |
| 2.40, Аноним (41), 15:26, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Так историю и так можно переписывать историю, через git rebase, а через git push --force можно и удалённую.
| | |
| |
| 3.61, Аноним (-), 17:18, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Так историю и так можно переписывать историю, через git rebase, а через
> git push --force можно и удалённую.
Можно. Но чаще всего лучше не стоит. Ибо если ты пушшанеш с форсом - у всех кто синкался оттуда - отъедет этот бранч. И его фикс потребует мануальщины. Т.е. вот именно незаметно подпихнуть левак - ну вот не. Это будет очень заметный и ломовой десинк, когда pull просто совсем не проходит - и ты либо мануально его захреначиваешь, либо думаешь что вообще с этйо ситуацией делать и выясняешь что там за нахрен с этим зеркалом.
| | |
| |
| 4.89, Аноним (89), 21:42, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Утрутся. Что вечно на SHA1 сидеть, или с километровыми блобами в репозитории, закомиченных в него недоумками по началу, а потом только сообразившими, что репозиторий именно из-за этого стал километровым? Или в очень большом репозитории с многолетней историей - с репозиторием на многие гига? Иногда практичнее чтобы те, кто PR отправили, утёрлись, git format-patch -1, git am ./*.patch, не впервой, утрутся, чем репозиторий в таком жутком состоянии держать.
| | |
| 4.100, Аноним (100), 00:44, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Если pull с авто-rebase (как оно и должно быть), то ничего не отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.
| | |
|
| 3.95, ыыыыы (?), 23:12, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Нельзя делать git push --force
Можно git push --force-with-lease --force-if-includes
| | |
|
|
| 1.45, Аноним (45), 15:45, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ] | +1 +/– | Я бы сказал самая адекватная система Не плохая, не хорошая, а просто соответств... большой текст свёрнут, показать | | |
| |
| 2.46, Александр (??), 16:05, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Проблема ртути не в тренде, а с его сообществе - после ухода его создателя, оставшиеся фаны вместо развития функционала занимаются переписыванием и стилизацией. Причем походу их неволнует ни функционал ни легаси - куча сторонних плагинов. В последней версиии отвалилась даже тортила. Но зато ори бодро мигрируют на раст.
За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR, они неприемлют эту простую и общепринятую технику, вместо этого пытаются завести велосипед с треугольными колесами блин - топики на эволюции. Как оно должно работать? Ни толкового дока, ни сапорта - я так и не смог в их девел ничего закинуть.
Патчи им кидать - только почтой, но почтой щас паришся клиент подключать (гмайл так вообще прикрыл лавочку кж пару лет) а в багтрекере патчи класть - они принципиально не признают.
И так у них во всем, всё на принципах, хоть код не расти. Ртуть главной репой брал смм фейсбук, и они таки её нехило допиливали. И где их труды? Разосрались видать и пошли разными лесами.
Так что проблема ртути в том что у нее рано ушел создатель, и больше визионеров адекватов там не осталось
| | |
| |
| 3.62, Аноним (-), 17:22, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Проблема ртути не в тренде, а с его сообществе -
Ее проблема в том что вместо удачных технологических решений и решения проблем они удумали хайповать с своим питончиком с 1 стороны (получив бонусом 100500 проблем перфоманса которых гит не имел и рассказы как не тормозит на 20% лучше в каждой версии) - и потом еще подарок в виде питона 3 который федот - но не тот, что совсем уж их и вбило в гроб.
А бонусом еще - аппелировать к необучашкам с CVS и SVN удумали - собрав все сливки общества.
| | |
| |
| 4.91, Аноним (91), 21:47, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке - долго и нудно по объектику.
| | |
|
| 3.70, Аноним (45), 18:04, 21/04/2026 [^] [^^] [^^^] [ответить] | +/– | Отчасти согласен, но всё перечисленное фактически уже следствие Даже уход mpm ... большой текст свёрнут, показать | | |
| 3.90, Аноним (90), 21:45, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Из Mercurial ущёл создатель, то есть его угроз засудить любого, кто посмеет сделать совместимый продукт, можно уже не опасаться?! Это офигенно, но как-то плохо верится, если бы ущёл создатель, то на опеннете была бы новость наверняка.
| | |
| 3.102, Аноним (1), 10:23, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR
Где сделать? Прям в ртути? А git'е оно как нормально сделано (именно в git-е, а не в гитхабе, гитлабе и тд)?
| | |
|
| 2.47, Александр (??), 16:06, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Проблема ртути не в тренде, а с его сообществе - после ухода его создателя, оставшиеся фаны вместо развития функционала занимаются переписыванием и стилизацией. Причем походу их неволнует ни функционал ни легаси - куча сторонних плагинов. В последней версиии отвалилась даже тортила. Но зато ори бодро мигрируют на раст.
За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR, они неприемлют эту простую и общепринятую технику, вместо этого пытаются завести велосипед с треугольными колесами блин - топики на эволюции. Как оно должно работать? Ни толкового дока, ни сапорта - я так и не смог в их девел ничего закинуть.
Патчи им кидать - только почтой, но почтой щас паришся клиент подключать (гмайл так вообще прикрыл лавочку кж пару лет) а в багтрекере патчи класть - они принципиально не признают.
И так у них во всем, всё на принципах, хоть код не расти. Ртуть главной репой брал смм фейсбук, и они таки её нехило допиливали. И где их труды? Разосрались видать и пошли разными лесами.
Так что проблема ртути в том что у нее рано ушел создатель, и больше визионеров адекватов там не осталось
| | |
| 2.50, Джон Титор (ok), 16:29, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> В целом я считаю Mercurial лучше
Я с этим согласен.
> С развитием AI-агентов эти тренды только усиливаются, "главное быстро и работает", "агент разберется, я что сам эти команды набираю".
Эх..
| | |
| 2.64, Смузихлеб забывший пароль (?), 17:42, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Эти рассказы про "как надо" у ртути чем-то напоминают сказки про бздю и академических академиков которые якобы тоже делают только как правильно, как надо и как должно быть в отличие от линя.
Но по сути, это именно что сказки. Дырок в бздях как в сыре и косяков/недоработок не меньше. А работа идёт медленней не потому что кто-то там слишком много думает и продумывает, а тупо потому что они получают меньше бабла, да и к самим системам сильно меньше интереса.
| | |
|
| 1.49, Джон Титор (ok), 16:25, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
О, помню у меня был коллега который любил подставить через изменение коммитов. Хорошо что ошибки при этом делал, которые можно доказать. Изменение истории конечно хорошо, если имеешь дело с адекватными людьми или ИИ, порой это нужно. Но я бы предпочел историю без изменений вообще - если что не так сделано - пусть будет новый комит с исправлениями. А если комментарий не такой как нужно, ну пусть будут какие-то заметки ещё, которые можно только добавлять. А перебазирование так вообще порой какие-то интересные вещи добавляет, особенно если через него делают PR. Зато совокупность комитов вместе и это вместо того чтобы делать сквош.
| | |
| 1.65, Аноним (65), 17:43, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Обычному разрабу достаточно юзать любой гуй, хоть Git Extension на винде или встроенный в IDE. А эти извращения только релизеру, который пытается собрать проект от своих разрабов, и то если все пошло не плану и перемешалось так что черт ногу сломит.
| | |
| |
| 2.67, Аноним (65), 17:50, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
но если этот релизер или тимлид не участвовал сам в разработке, то никакие ухищрения с гитом не помогут ему правильно собрать ветки
| | |
|
| 1.68, Аноним (68), 18:00, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Недавно, недели 3 назад, ещё вышла Jujutsu-VCS (jj-vcs) v0.40.0 — современная замена Git от Google, написанная на безопасном по памяти языке Rust
| | |
| |
| 2.104, Аноним (1), 10:25, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Уж лучше got от OpenBSD, чем что-то от гугла... тем более на безопасном языке.
| | |
|
| 1.82, Аноним (82), 19:22, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Годно, нужно, мощно, молодёжно. Использую в связке Astro + MDX + Git.
| | |
|