| |
| 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
Особенно потрясающе там теги и субмодули были сделаны, с которыми никогда не знаешь, в какую репу коммитишь.
| | |
| |
| 5.105, Аноним (-), 12:31, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Особенно потрясающе там теги и субмодули были сделаны, с которыми никогда не
> знаешь, в какую репу коммитишь.
Да там для начала просто скачать новую версию мало-мальски крупного проекта - мучение и позор. Так что вот именно мотание между версиями - мучительно, медленно, требует перекачки половины интернета и занимает совершенно неадекватное время.
И тут гит такой за несколько секунд мне запрошенную версию linux kernel - хренась, раскатывает как из пушки! Ну что, "система контроля версий" версии то надо было контролировать - вот как-то так.
| | |
| 5.127, Аноним (38), 18:36, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ну субмодули, справедливости ради, именно для этого и были сделаны - прозрачно коммитить в другую репу, и в git они работают так же.
| | |
|
|
| 3.98, OpenEcho (?), 23:57, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Можно подумать есть выбор.
Ну вон sqlite вполне себе обходится fossil-scm, который по ходу all-in-one и трекер и форум и вики и SCM и всё в одном флаконе, а с "миром" (с гитом т.е.) через импорт/экспорт
| | |
| |
| 4.111, Аноним (38), 15:16, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
sqlite обходится этой noдeлкoй потому что это noдeлкa того же автора (причём чсх контрибушоны он не принимает, т.е. флоу совместной разработки через fossil вообще не использует и даже не представляет насколько он ужасен). Больше никто её не использует.
> а с "миром" (с гитом т.е.) через импорт/экспорт
Нет, импорт/экспорт это именно импорт/экспорт - одноразовое действо для переезда туда или оттуда. Это не синхронизация, с гитом там взаимодействовать полноценно не получится. Но понятно что контрибуторам ничего не останется кроме как делать экспорт в git, в git нормально разрабатываться и потом как-то слать обратно патч.
| | |
|
|
| 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 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> ... называется hg.
Месиво на питоне который нетормозит (так что каждую версию рассказывали на сколько именно неторможение улучшено). И который отлично совместим между версиями. Но правда к моменту дропа версии 2 - коса нашла на камень и столько кода переписать до потери актуальности господа просто не смогли нормально.
| | |
| |
| |
| 5.118, Аноним (-), 17:19, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> что с ним надо делать, чтоб он тормозил?
Поворочать им проект чуть крупнее чем я и мой хелловорлд. Линух кернел в него загони с всеми ревизиями и посмотри как тебе ЭТО будет. А гиту нормально, фигли.
| | |
|
|
|
| 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
И как же она заменит систему контроля версий?
| | |
| |
| 5.113, Аноним (38), 15:24, 22/04/2026 [^] [^^] [^^^] [ответить] | +/– | С большинством бинарных форматов в этом нет смысла, ибо они меняются целиком Вс... большой текст свёрнут, показать | | |
| |
| 6.116, ptr (ok), 16:26, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
>> Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком.
> С большинством бинарных форматов в этом нет смысла, ибо они меняются целиком.
А считали как? Лёжа на диване по мухам на потолке? )))
У среднего пользователя на компе видеофайлы имеют в среднем на порядок больший объём, чем все остальные бинарные файлы вместе взятые.
> Возможно это только до следующего gc. Если там действительно меняются только ключевые
> кадры, общие части схлопнутся дельта компрессией при создании pack'а.
Я же писал - проверьте. Не применяется дельта-компрессия в git к бинарным файлам более-менее приличного размера. Он тупо складывает их в LFS.
> прочем, не понимаю зачем результат процессинга хранить в VCS. Хранится исходный
> ролик и настройки субтитров.
Потому что читать не умеете. Субтитры и титры названия ролика - очень даже разные вещи.
Хотя могу предложить при редактировании "замедлить" или "ускорить" трехсекундный фрагмент.
Я уже молчу про REDCODE или Apple ProRes с битрейтом в гигабиты, когда создание даже рекламного ролика может произвести сотню терабайт версий, если не выделять дельту в бинарных данных.
> Что значит заменит систему контроля версий? Это часть git.
Которая хранит каждую версию файла целиком, а не дельту. Про что и речь.
| | |
| |
| 7.119, Аноним (-), 17:21, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> А считали как? Лёжа на диване по мухам на потолке? )))
> У среднего пользователя на компе видеофайлы имеют в среднем на порядок больший
> объём, чем все остальные бинарные файлы вместе взятые.
Вот только при изменении видеофайла он тоже чаще всего меняется - почти на 100%, от и до. И вообще - система контроля версий исходников - все же не CDN для доставки видео.
Бывают всякие смежные кейсы иногда. Но они редкие и в целом решаемые.
| | |
| |
| 8.125, ptr (ok), 17:53, 22/04/2026 [^] [^^] [^^^] [ответить] | +/– |  Вы очень плохо знаете форматы видеофайлов Ещё с MPEG-1 модификация видеофайла н... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 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 [^] [^^] [^^^] [ответить]
| +1 +/– |
Монополия в 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 - фигня какая то запутанная, тормозная и перегруженная - никогда там ничего что надо не найти.
| | |
| |
| 7.120, Аноним (-), 17:23, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> GitLab - фигня какая то запутанная, тормозная и перегруженная - никогда там
> ничего что надо не найти.
Но на самом деле по своему крут для "большого" прожектманагемента. Если у тебя голимый патч - он конечно избыточен для этого. А если здоровый проект из кучи частей и проч - таки норм.
Правда тормозной он конечно да. И барахла в нем много. В этом смысле если более лайтово хотелось - gogs-образные, типа gitea/forgejo/как их там (деривативы gogs) явно лучше.
| | |
|
| 6.117, Аноним (74), 17:11, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Наоборот, GitHub оказался просто ПЕРВОЙ единственной серьёзно, нормально, с душой, слепленной социалочкой для кодеров
Очевидно, всяких форже ты не застал. Когда они были лидерами. У них был один недостаток. Они были не для git.
| | |
| |
| 7.121, Аноним (-), 17:24, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Очевидно, всяких форже ты не застал. Когда они были лидерами. У них
> был один недостаток. Они были не для git.
Они были - бесплатным хостингом для виндоблобов и характерными девами с CVS и SVN. За что и пострадали. Нормальные девелоперы выбрали git - а даунлоады они и сами себе нарулить с этим своим linux могут.
| | |
|
|
|
|
|
|
| |
| |
| 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 комитов на свое счастье. Внятно оформить свое счастье и ребэйзнуть на что-то более новое? Не, вы что, это слишком просто. Вот елси профайинг вместо этого затеять...
| | |
| |
| 7.114, Аноним (38), 15:33, 22/04/2026 [^] [^^] [^^^] [ответить] | +/– | Что значит реплеят и в чём разница с ребейзнуть Если ты про схлопнуть в оди... большой текст свёрнут, показать | | |
|
|
|
|
|
| 2.59, Аноним (-), 17:16, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> У меня rebase всегда какой то медленный, вот бы его ускорили.
А что ты с ним делаешь чтобы он был медленный? Реплеишь 100500 комитов? Ну так отребэйзь свои чудо-патчи на что-нибудь более новое - быстрее будет. Потому что меньше комитов реплеить.
| | |
| |
| 3.80, Аноним83 (?), 18:57, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Я выше написал как я делаю.
Что вы предлагаете?
Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану.
| | |
| |
| 4.123, Аноним (-), 17:31, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану.
Ну так ребэйзни свой бранч с ними или что там у тебя на более новую версию апстрима - и число комитов которые надо аплаить при rebase радикально скостится.
Да, коенчно если это делать раз в сто лет - и апстрим активный и навалит патчей - их реплей по цепочке станет занимать энное время. Просто дельту не стоит сильно отращивать и свои фичи ребейзить на актуальные комиты апстрима периодически. А не раз в сто лет или с продолбом результата этого и реаплаем каждый раз.
| | |
|
|
|
| 1.23, RM (ok), 14:24, 21/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
git rip?
из текста новости
Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите,
и ниже
Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений
| | |
| |
| 2.33, Аноним (38), 14:54, 21/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ох. Тебе рассказать чем отличается локальная история от публичной? Не, иди сам почитай.
| | |
| 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, не впервой, утрутся, чем репозиторий в таком жутком состоянии держать.
| | |
| |
| 5.107, Аноним (-), 12:43, 22/04/2026 [^] [^^] [^^^] [ответить] | +/– | Таки можно и вечно сидеть SHA1 вообще не столько секурити фич сколько техническ... большой текст свёрнут, показать | | |
|
| 4.100, Аноним (100), 00:44, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Если pull с авто-rebase (как оно и должно быть), то ничего не отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.
| | |
| |
| 5.124, Аноним (-), 17:35, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Если pull с авто-rebase (как оно и должно быть), то ничего не
> отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.
Да вот понимаешь ли, я могу чисто технически сделать push --force чего-то совсем радикально иного - на что ремоты - таки - десинхронизируются. И обучать их там всех правильно пул делать - ну тоже такое себе.
Пожтому лично я push --force практикую только для мелких фич in flight с 1-3 интересантами. Если это не оно я подумаю о альтернативах.
| | |
|
|
| 3.95, ыыыыы (?), 23:12, 21/04/2026 [^] [^^] [^^^] [ответить]
| +1 +/– |
Нельзя делать 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 [^] [^^] [^^^] [ответить]
| +/– |
Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке - долго и нудно по объектику.
| | |
| |
| 5.108, Аноним (-), 12:48, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке -
> долго и нудно по объектику.
Не имею никаких проблем с скоростью клонирования репо в гите. Ворочая штуками с линухкернел размером. Теперь попробуйте вообще поворочать чем-то таким в hg - и мы поговорим кто там и что нудно делает, у кого перфоманс - отстойный, и что и где не тормозит.
Конечно в любом мало-мальски сложном софте всегда можно к чему-нибудь придраться. Но в среднем по больнице git обставил этого не тормозящего - как с куста. С бранчами эта хрень тоже делает что-то левое, в угоду каким-то необучахам с svn или типа того. А в гите бранчи и теги работают именно так как это и ожидается, без факапов и костылей.
| | |
|
|
| 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 [^] [^^] [^^^] [ответить]
| +/– |
Эти рассказы про "как надо" у ртути чем-то напоминают сказки про бздю и академических академиков которые якобы тоже делают только как правильно, как надо и как должно быть в отличие от линя.
Но по сути, это именно что сказки. Дырок в бздях как в сыре и косяков/недоработок не меньше. А работа идёт медленней не потому что кто-то там слишком много думает и продумывает, а тупо потому что они получают меньше бабла, да и к самим системам сильно меньше интереса.
| | |
| 2.129, Аноним (38), 18:43, 22/04/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Например, его более бережное отношение к истории.
Бережное отношение к истории - это сделать фичу, разбить её на topic коммиты отражающие стадии её внедрения и в таком виде влить. Те кто считают "бережным отношением к истории" необходимость фиксировать всю промежуточную работу, включая несобирающийся код, debug принты, закоммиченные по ошибке секреты и выходные файлы, не закоммиченные по ошибке исходники, к индустрии никакого отношения, действительно, не имеют.
| | |
|
| 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.
| | |
| 1.126, Аноним (126), 17:57, 22/04/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Гит обрастает хламом. С каждым новым релизом он всё дальше от бога. Идеал — когда нечего убрать и все рабочие потребности закрыты полностью. Гит идет обратной дорогой — наваливает все больше функций, а свою основную работу делает кое-как (не надо делать вид, что сломанная репа это целиком вина разработчика).
Вот в коментах упоминают Ртуть. Она почти мертва и мало кем используется, но при этом в ней есть всё что нужно для работы. Я пользуюсь ей для своих проектов. Ртуть ни разу не делала мне голову в отличии от гита. Всё таки смерть — это настояший релиз программы. Миллионы мух летят дальше на новый релиз более модной технологии, а ты ценишь покой, когда в "умершей" программе всё изучено и работает без суеты.
| | |
| |
| 2.130, Гуманоид (?), 01:45, 23/04/2026 [^] [^^] [^^^] [ответить]
| +/– |
Аналогично, для себя только ртуть. Меркуриал сделан для людей. Git сделан для погромистов.
| | |
|
|