Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск системы управления исходными текстами Git 2.54"	+/–
Сообщение от opennews (??), 21-Апр-26, 12:31
Представлен релиз распределенной системы управления исходными текстами Git 2.54. Git отличается высокой производительностью  и  предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.  Код Git распространяется под лицензией GPLv2+... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=65252
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 21-Апр-26, 12:31	+8 +/–
Лучшая система контроля версий ever.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #4, #5, #20, #44, #78

2. Сообщение от Аноним (2), 21-Апр-26, 12:33	–4 +/–
cvs лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3, #27

3. Сообщение от Аноним (3), 21-Апр-26, 12:40	–1 +/–
нет, рар
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от Аркагоблин (?), 21-Апр-26, 12:41	–1 +/–
Можно подумать есть выбор. GitHub, GitLab, даже Codeberg - всё заточено на Git. Да, можно найти маргинальный сервис с чем-то другим, но если у кода не появится пользователей (а там их точно не появится!), то зачем тогда публиковать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #21, #38, #41, #56, #98

5. Сообщение от Аноним (5), 21-Апр-26, 12:43	+2 +/–
>Лучшая система контроля версий ever. Нету конкурентов. BitKeeper послал ядро и Линуса, ядро и Линус послало биткипера, так появился гит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #24, #29

6. Сообщение от Sm0ke85 (ok), 21-Апр-26, 12:43	–1 +/–
>Выпуск системы управления исходными текстами Git 2.54 Заголовок не точный... ``` Git — распределённая система управления Версиями. ```
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #30

7. Сообщение от Аркагоблин (?), 21-Апр-26, 12:48	+5 +/–
Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #14, #16, #26, #31

8. Сообщение от Аноним83 (?), 21-Апр-26, 12:54	+/–
У меня rebase всегда какой то медленный, вот бы его ускорили.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #59

9. Сообщение от аврварвар (?), 21-Апр-26, 12:55	+1 +/–
Новую СКВ сделать немножко проще, чем новое светило.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

13. Сообщение от Аноним (13), 21-Апр-26, 13:24	–3 +/–
и зачем ты делаешь rebase?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #18, #28

14. Сообщение от Аноним (1), 21-Апр-26, 13:36	–1 +/–
Мне плевать на монополию и какие-то там приложения, которые её используют (кстати, что это за приложения?). Я оцениваю по объективным признакам - она просто самая лучшая из тех, что существуют или когда-либо существовали: rcs, cvs, svn, fossil, hg
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #15, #17

15. Сообщение от Аркагоблин (?), 21-Апр-26, 13:50	+1 +/–
Объективным качествам? Так древнеарамейский язык может тоже качественный, но если на нём не с кем общаться и его нельзя применить на практике, то и его качество бесполезно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

16. Сообщение от Аноним (16), 21-Апр-26, 13:56	+2 +/–
Она не лучшая СКВ, но монополий там, где действуют сетевые эффекты, избежать невозможно. А в СКВ они особенно сильны. Просто все проприетарщики кроме гитхаба оказались клиническими д********и и просрали все полимеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

17. Сообщение от Аноним (3), 21-Апр-26, 14:00	+/–
ну т.е. реального монополиста, perforce, ты в глаза не видел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #36

18. Сообщение от Аноним83 (?), 21-Апр-26, 14:04	+/–
Потому что у меня набор локальных патчей, и я периодически подтягиваю с апстрима свежее и мне надо чтобы мои коммиты накатились сверху. В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно. В моём представлении там всего то надо вызывать patch, потом git add, git commit. Учитывая что оно делается внутри одного бинарника то я ожидаю что с моми диффами в 1кб оно должно работать непрелично быстро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #32, #35

20. Сообщение от IMBird (ok), 21-Апр-26, 14:09	–2 +/–
... называется hg.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #58

21. Сообщение от Аноним (21), 21-Апр-26, 14:11	+3 +/–
Не понял смысл твоего мутного высера. Лично где ты был когда игнорировали Mercurial?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #86

22. Сообщение от Аноним (21), 21-Апр-26, 14:12	+1 +/–
Точнее будет так. Система колективного написания кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

23. Сообщение от RM (ok), 21-Апр-26, 14:24	+/–
git rip? из текста новости Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, и ниже Реализована команда "git history", предоставляющая экспериментальные возможности для перезаписи истории изменений
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33, #37, #40

24. Сообщение от Аноним (24), 21-Апр-26, 14:25	+/–
Юникс послал гну и ядро и так появился Линукс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #57

26. Сообщение от Аноним (24), 21-Апр-26, 14:27	+/–
Не посещала мысль, что монополия это плохо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #34, #76, #79

27. Сообщение от Аноним (27), 21-Апр-26, 14:38	+7 +/–
src_yyyy.mm.dd.zip же!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #97

28. Сообщение от Аноним (27), 21-Апр-26, 14:40	+1 +/–
А ты ветки мержишь? Серьёзно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #42, #52

29. Сообщение от Аноним (38), 21-Апр-26, 14:44	+1 +/–
Ой, конкурентов навалом было - инвалидный hg, маргинальные фоссилы и пихули, математичный darcs ажно основанный на patch theory. История рассудила.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

30. Сообщение от Аноним (38), 21-Апр-26, 14:45	+/–
Изначальный заголовок правильный, версиями тут никаким боком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

31. Сообщение от Аноним (38), 21-Апр-26, 14:50	+/–
> Говорить что Git - лучшая СКВ это всё равно, что говорить что Солнце - лучшее светило. У неё монополия, все сервисы и приложения используют именно её, и она вне конкуренции. Ну да, а монополией её сделал лично Линус, потому что ходил по домам разработчиком и сносил им другие VCS. Нет, она монополия именно потому что лучшая. У hg были все шансы, он не взлетел. У большинства VCS-новоделов есть интероп с гитом, поэтому тоже все шансы, но кто ими пользуется?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #66

32. Сообщение от Аноним (38), 21-Апр-26, 14:53	+/–
Тоже такое замечал на дереве портов FreeBSD (хотя это огромный реп). Стоило бы это попрофайлить, но пока недостаточно чешется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #51

33. Сообщение от Аноним (38), 21-Апр-26, 14:54	+/–
Ох. Тебе рассказать чем отличается локальная история от публичной? Не, иди сам почитай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

34. Сообщение от Аноним (38), 21-Апр-26, 14:57	+/–
Конечно плохо, это же в первом классе рассказывают. Безусловно нужно демонополизировать и пользоваться 2-3 несовместимыми VCS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #54

35. Сообщение от Аноним (41), 21-Апр-26, 15:07	+/–
>В одном случае их 20, в другом 60 и занимает это каждый раз как то неприлично много времени - на каждый коммит по 1 секунде примерно. Помещаете в переменные $from указатель на последний коммит из родительской ветки, $to - последний нужный вам коммит, это можно автоматизировать, опираясь на ваш подход, после чего делаете git diff "$from..$to" | git apply git add . git commit -m 'one commit' Данная команда сожмёт всё в один коммит. Можно расписать более сложную логику, например через git log --name-only получать список имён, но это уже делать вам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #53

36. Сообщение от Аноним (36), 21-Апр-26, 15:10	+/–
При MS головного мозга что угодно может привидеться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

37. Сообщение от Аноним (1), 21-Апр-26, 15:13	–1 +/–
У себя на локалхосте переписывай историю как хочешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #88

38. Сообщение от Аноним (38), 21-Апр-26, 15:23	+1 +/–
Для альтернативно одарённых есть новодельные vcs совместимые с гитовым хранилищем, например jj. Попробуйте, расскажете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

40. Сообщение от Аноним (41), 21-Апр-26, 15:26	+/–
Так историю и так можно переписывать историю, через git rebase, а через git push --force можно и удалённую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #61, #95

41. Сообщение от Аноним (41), 21-Апр-26, 15:28	+/–
>GitLab, даже Codeberg - всё заточено на Git Нужен либо аналог, либо поддержка в одном из. >то зачем тогда публиковать? Поднимайте зеркало, и публикуйте и там и там, в чём проблема?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #48

42. Сообщение от Аноним (42), 21-Апр-26, 15:39	+/–
А как правильно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

44. Сообщение от Аноним (-), 21-Апр-26, 15:45	+2 +/–
Dacrs/Pijul?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

45. Сообщение от Аноним (45), 21-Апр-26, 15:45	+1 +/–
Я бы сказал самая адекватная система. Не плохая, не хорошая, а просто соответствующая текущим реалиям. В целом я считаю Mercurial лучше, даже я сказал бы корректнее, но индустрии в целом его плюсы оказались не так важны. Например, его более бережное отношение к истории. Но индустрии важно "сейчас", а не "как это получено". Или скажем более простая и последовательная система команд и изначальный прицел на распределенность (а ля, разработчики легко могут тянуть комиты друг-друга напрямую). Но индустрия в целом заинтересована в централизации и контроле, пусть с "расширенным offline-режимом". Поэтому Mercurial не адекватен текущему тренду индустрии. С развитием AI-агентов эти тренды только усиливаются, "главное быстро и работает", "агент разберется, я что сам эти команды набираю". А история комитов, агентам она по факту и не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46, #47, #50, #64, #129

46. Сообщение от Александр (??), 21-Апр-26, 16:05	+/–
Проблема ртути не в тренде, а с его сообществе - после ухода его создателя, оставшиеся фаны вместо развития функционала занимаются переписыванием и стилизацией. Причем походу их неволнует ни функционал ни легаси - куча сторонних плагинов. В последней версиии отвалилась даже тортила. Но зато ори бодро мигрируют на раст. За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR, они неприемлют эту простую и общепринятую технику, вместо этого пытаются завести велосипед с треугольными колесами блин - топики на эволюции. Как оно должно работать? Ни толкового дока, ни сапорта - я так и не смог в их девел ничего закинуть. Патчи им кидать - только почтой, но почтой щас паришся клиент подключать (гмайл так вообще прикрыл лавочку кж пару лет) а в багтрекере патчи класть - они принципиально не признают. И так у них во всем, всё на принципах, хоть код не расти. Ртуть главной репой брал смм фейсбук, и они таки её нехило допиливали. И где их труды? Разосрались видать и пошли разными лесами. Так что проблема ртути в том что у нее рано ушел создатель, и больше визионеров адекватов там не осталось
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #62, #70, #90, #102

47. Сообщение от Александр (??), 21-Апр-26, 16:06	+/–
Проблема ртути не в тренде, а с его сообществе - после ухода его создателя, оставшиеся фаны вместо развития функционала занимаются переписыванием и стилизацией. Причем походу их неволнует ни функционал ни легаси - куча сторонних плагинов. В последней версиии отвалилась даже тортила. Но зато ори бодро мигрируют на раст. За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR, они неприемлют эту простую и общепринятую технику, вместо этого пытаются завести велосипед с треугольными колесами блин - топики на эволюции. Как оно должно работать? Ни толкового дока, ни сапорта - я так и не смог в их девел ничего закинуть. Патчи им кидать - только почтой, но почтой щас паришся клиент подключать (гмайл так вообще прикрыл лавочку кж пару лет) а в багтрекере патчи класть - они принципиально не признают. И так у них во всем, всё на принципах, хоть код не расти. Ртуть главной репой брал смм фейсбук, и они таки её нехило допиливали. И где их труды? Разосрались видать и пошли разными лесами. Так что проблема ртути в том что у нее рано ушел создатель, и больше визионеров адекватов там не осталось
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

48. Сообщение от Аркагоблин (?), 21-Апр-26, 16:10	+/–
А зачем мне публиковать и там и там? Только ради другой СКВ, чтобы показать "что у меня не git"? Нет, спасибо
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #81

49. Сообщение от Джон Титор (ok), 21-Апр-26, 16:25	+/–
О, помню у меня был коллега который любил подставить через изменение коммитов. Хорошо что ошибки при этом делал, которые можно доказать. Изменение истории конечно хорошо, если имеешь дело с адекватными людьми или ИИ, порой это нужно. Но я бы предпочел историю без изменений вообще - если что не так сделано - пусть будет новый комит с исправлениями. А если комментарий не такой как нужно, ну пусть будут какие-то заметки ещё, которые можно только добавлять. А перебазирование так вообще порой какие-то интересные вещи добавляет, особенно если через него делают PR. Зато совокупность комитов вместе и это вместо того чтобы делать сквош.
Ответить | Правка | Наверх | Cообщить модератору

50. Сообщение от Джон Титор (ok), 21-Апр-26, 16:29	+/–
> В целом я считаю Mercurial лучше Я с этим согласен. > С развитием AI-агентов эти тренды только усиливаются, "главное быстро и работает", "агент разберется, я что сам эти команды набираю". Эх..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

51. Сообщение от Аноним83 (?), 21-Апр-26, 16:39	+1 +/–
Так вот и не понятно, вроде ничего тяжёлого быть не должно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

52. Сообщение от Аноним83 (?), 21-Апр-26, 16:40	+/–
Нет. git -C /usr/ports/ pull --rebase upstream main git -C /usr/ports/ push -f origin main
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #55

53. Сообщение от Аноним83 (?), 21-Апр-26, 16:41	+/–
Мне один коммит не нужен и вреден.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

54. Сообщение от Аноним (54), 21-Апр-26, 16:44	–1 +/–
Да один фюрер, один народ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #75

55. Сообщение от Аноним (54), 21-Апр-26, 16:45	–1 +/–
Ужасно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #63

56. Сообщение от Аноним (-), 21-Апр-26, 17:01	–2 +/–
>  Можно подумать есть выбор. GitHub, GitLab, даже Codeberg - всё заточено на Git. Ну так был sourceforge, тормозил с гитом по упора, сватая "отличные" CVS и SVN - и где они теперь? По сравнению с git - и то и другое это архаичное назойливое г-но которое как раз контроль версий нормально выполнять и не может. Это похабные качалки с ремоты, почему-то названые системой контроля версий. Что не соответствует действительности - именно по версиям мотаться этой похабщиной было мучительно, медленно и качало половину интернета на любой пшик. Был bitbucket. Сватавший недоразумение hg. С достоинством "как гит затонапитончике". С целевой аудиторией - неоьучашки которых не попустил cvs и svn. Достоинство оказалось так себе. Мягко говоря. Оно тормозило что капец, а в подборочку юзеров отфильтровались ну такие себе господа. Есть всякие штуки типа DARCS или там Fossil - но они просто не от мира сего и решают какие-то странные проблемы. Яввно не does one thing (version control) and does it well.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #77

57. Сообщение от Аноним (-), 21-Апр-26, 17:02	+/–
>  Юникс послал гну и ядро и так появился Линукс. Наоборот. Но суть в целом не меняет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

58. Сообщение от Аноним (-), 21-Апр-26, 17:13	+2 +/–
> ... называется hg. Месиво на питоне который нетормозит (так что каждую версию рассказывали на сколько именно неторможение улучшено). И который отлично совместим между версиями. Но правда к моменту дропа версии 2 - коса нашла на камень и столько кода переписать до потери актуальности господа просто не смогли нормально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #110

59. Сообщение от Аноним (-), 21-Апр-26, 17:16	+/–
> У меня rebase всегда какой то медленный, вот бы его ускорили. А что ты с ним делаешь чтобы он был медленный? Реплеишь 100500 комитов? Ну так отребэйзь свои чудо-патчи на что-нибудь более новое - быстрее будет. Потому что меньше комитов реплеить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #80

60. Сообщение от Аноним (60), 21-Апр-26, 17:16	–2 +/–
VCS не стоят на месте, из последнего Ark выглядит шикарно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73

61. Сообщение от Аноним (-), 21-Апр-26, 17:18	+/–
> Так историю и так можно переписывать историю, через git rebase, а через > git push --force можно и удалённую. Можно. Но чаще всего лучше не стоит. Ибо если ты пушшанеш с форсом - у всех кто синкался оттуда - отъедет этот бранч. И его фикс потребует мануальщины. Т.е. вот именно незаметно подпихнуть левак - ну вот не. Это будет очень заметный и ломовой десинк, когда pull просто совсем не проходит - и ты либо мануально его захреначиваешь, либо думаешь что вообще с этйо ситуацией делать и выясняешь что там за нахрен с этим зеркалом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #89, #100

62. Сообщение от Аноним (-), 21-Апр-26, 17:22	+/–
> Проблема ртути не в тренде, а с его сообществе - Ее проблема в том что вместо удачных технологических решений и решения проблем они удумали хайповать с своим питончиком с 1 стороны (получив бонусом 100500 проблем перфоманса которых гит не имел и рассказы как не тормозит на 20% лучше в каждой версии) - и потом еще подарок в виде питона 3 который федот - но не тот, что совсем уж их и вбило в гроб. А бонусом еще - аппелировать к необучашкам с CVS и SVN удумали - собрав все сливки общества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #91

63. Сообщение от Аноним (63), 21-Апр-26, 17:37	+/–
> Ужасно Они там в BSD - CVS и SVN покусаны и поэтому напрочь не одупляют как работает git. Они и реплеят ударными темпами 100500 комитов на свое счастье. Внятно оформить свое счастье и ребэйзнуть на что-то более новое? Не, вы что, это слишком просто. Вот елси профайинг вместо этого затеять...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #114

64. Сообщение от Смузихлеб забывший пароль (?), 21-Апр-26, 17:42	+/–
Эти рассказы про "как надо" у ртути чем-то напоминают сказки про бздю и академических академиков которые якобы тоже делают только как правильно, как надо и как должно быть в отличие от линя. Но по сути, это именно что сказки. Дырок в бздях как в сыре и косяков/недоработок не меньше. А работа идёт медленней не потому что кто-то там слишком много думает и продумывает, а тупо потому что они получают меньше бабла, да и к самим системам сильно меньше интереса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

65. Сообщение от Аноним (65), 21-Апр-26, 17:43	+/–
Обычному разрабу достаточно юзать любой гуй, хоть Git Extension на винде или встроенный в IDE. А эти извращения только релизеру, который пытается собрать проект от своих разрабов, и то если все пошло не плану и перемешалось так что черт ногу сломит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67

66. Сообщение от Аркагоблин (?), 21-Апр-26, 17:48	–1 +/–
Монополией её сделал GitHub, а не Линус
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #74

67. Сообщение от Аноним (65), 21-Апр-26, 17:50	+/–
но если этот релизер или тимлид не участвовал сам в разработке, то никакие ухищрения с гитом не помогут ему правильно собрать ветки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

68. Сообщение от Аноним (68), 21-Апр-26, 18:00	+/–
Недавно, недели 3 назад, ещё вышла Jujutsu-VCS (jj-vcs) v0.40.0 — современная замена Git от Google, написанная на безопасном по памяти языке Rust
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69, #71, #92, #104

69. Сообщение от Аноним (68), 21-Апр-26, 18:00	+/–
Она ещё совместима с Git
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #72

70. Сообщение от Аноним (45), 21-Апр-26, 18:04	+/–
Отчасти согласен, но всё перечисленное фактически уже следствие. Даже уход mpm. На счет PR - в целом да, с коротко-живущими ветками всё как-то не сложилось. Тут даже не в самой ртути проблема, а в том, что "надо как в github". А точного соответствия быть не могло, т.к. как в github означает "нам всё равно что и как происходит в ветке PR, важно только что замержится". И это очень отличается от парадигмы hg. Технически это конечно всё сделать можно, но зачем? Никто в принципе это не оценит, т.к. у индустрии в целом иной тренд. Итого гранты видимо только отрабатывают. На счет патчей раньше у них было вполне не плохо, реагировали оперативно. Сам пользовался hg и черепашкой лет наверное 18 и отдельно ив интеграции с svn, и с git. До сих пор считаю его одним из лучших клиентов, даже для работы с сервером git. Кое-где у меня еще работает с git.intree=1, т.к. вся история в hg часто в разы компактнее свежесклонированного git. Но в целом уже давно было понятно, что рано или поздно там всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

71. Сообщение от Сладкая булочка (?), 21-Апр-26, 18:11	+1 +/–
> современная замена Git от Google А google то ее использует? Почему chromium использует git?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

72. Сообщение от Сладкая булочка (?), 21-Апр-26, 18:12	+1 +/–
Ну вот git на posix shell https://git.sr.ht/~sircmpwn/shit
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

73. Сообщение от Сладкая булочка (?), 21-Апр-26, 18:16	+1 +/–
Проприетарщина.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

74. Сообщение от Аноним (74), 21-Апр-26, 18:17	+1 +/–
При десятке аналогов упирающихся в корявость альтернатив. github и стал популярен из-за заточенности на git в отличии от других.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #87

75. Сообщение от Аноним (75), 21-Апр-26, 18:27	–1 +/–
Котёнок с дверцей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

76. Сообщение от Аноним (76), 21-Апр-26, 18:32	+/–
Они тут все ща системд топят, не поймут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

77. Сообщение от Аноним (77), 21-Апр-26, 18:45	+/–
>SVN Особенно потрясающе там теги и субмодули были сделаны, с которыми никогда не знаешь, в какую репу коммитишь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #105, #127

78. Сообщение от ptr (ok), 21-Апр-26, 18:51	+/–
Смотря для чего. Если именно для текстов - да. Если же есть необходимость в системе контроля версий  для бинарных данных, то нет. C этим SVN справляется намного лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #84

79. Сообщение от Аноним (79), 21-Апр-26, 18:57	+1 +/–
Монополия в it-технологиях это какой-то оксюморон. Хотите - откапывайте для себя битбакеты, Линус со своим гитом вам не помешает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

80. Сообщение от Аноним83 (?), 21-Апр-26, 18:57	+/–
Я выше написал как я делаю. Что вы предлагаете? Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #123

81. Сообщение от Аноним (41), 21-Апр-26, 19:18	+/–
А зачем вам вообще нужна альтернатива гиту?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #83

82. Сообщение от Аноним (82), 21-Апр-26, 19:22	–1 +/–
Годно, нужно, мощно, молодёжно. Использую в связке Astro + MDX + Git.
Ответить | Правка | Наверх | Cообщить модератору

83. Сообщение от Аркагоблин (?), 21-Апр-26, 19:22	+/–
Лично мне не за чем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #85

84. Сообщение от Аноним (38), 21-Апр-26, 19:44	–1 +/–
> C этим SVN справляется намного лучше. И в чём лучшесть? Гиту, на самом деле, вообще по барабану какие данные трекать - с блобами он справляется также как с текстом, с большими блобами так же как с маленькими. Когда говорят о бинарных данных, обычно имеют в виду что не хотят хранить всю их историю локально. Для этого есть LFS, другой инструмент тащить совершенно не обязательно. Тем более SVN, который "лучше" не справляется вообще ни с чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #96

85. Сообщение от Аноним (38), 21-Апр-26, 20:09	+/–
Тогда к чему вообще был разговор про отсутствие выбора?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #93

86. Сообщение от ыыыыы (?), 21-Апр-26, 20:52	+2 +/–
Ушёл с меркуриала - ни о чём не жалею
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #109

87. Сообщение от Аноним (87), 21-Апр-26, 21:37	+1 +/–
Наоборот, GitHub оказался просто ПЕРВОЙ единственной серьёзно, нормально, с душой, слепленной социалочкой для кодеров, без лишней email-<предъявите ваш телефон и паспорт>-идиотии, а не наколеночным поделием, как остальные. Ну а что в GitHubе было - то и взлетело. Сам гитхаб прибил конкурентов за счёт тех же сетевых эффектов. В некоторые годы GitLab были намного лучше, но потом тоже хренеть начали, когда базу набирали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #94, #117

88. Сообщение от Аноним (88), 21-Апр-26, 21:38	+/–
Можно и не на локалхосте, а кому не нравится - утрутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

89. Сообщение от Аноним (89), 21-Апр-26, 21:42	+/–
Утрутся. Что вечно на SHA1 сидеть, или с километровыми блобами в репозитории, закомиченных в него недоумками по началу, а потом только сообразившими, что репозиторий именно из-за этого стал километровым? Или в очень большом репозитории с многолетней историей - с репозиторием на многие гига? Иногда практичнее чтобы те, кто PR отправили, утёрлись, git format-patch -1, git am ./*.patch, не впервой, утрутся, чем репозиторий в таком жутком состоянии держать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #107

90. Сообщение от Аноним (90), 21-Апр-26, 21:45	+/–
Из Mercurial ущёл создатель, то есть его угроз засудить любого, кто посмеет сделать совместимый продукт, можно уже не опасаться?! Это офигенно, но как-то плохо верится, если бы ущёл создатель, то на опеннете была бы новость наверняка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

91. Сообщение от Аноним (91), 21-Апр-26, 21:47	+/–
Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке - долго и нудно по объектику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #108

92. Сообщение от Аноним (92), 21-Апр-26, 21:48    Скрыто ботом-модератором	+/–
jj - это неюзабельное говно, GUI-клиентов нет, но что хуже - у неё модель работы какая-то неадекватная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

93. Сообщение от Аркагоблин (?), 21-Апр-26, 22:04	+1 +/–
Потому что вы сравниваете "лучший" и "не лучший" словно кроме Git есть реальные используемые людьми альтернативы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #128

94. Сообщение от Аноним83 (?), 21-Апр-26, 22:15	+/–
GitLab - фигня какая то запутанная, тормозная и перегруженная - никогда там ничего что надо не найти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #99, #120

95. Сообщение от ыыыыы (?), 21-Апр-26, 23:12	+1 +/–
Нельзя делать git push --force Можно git push --force-with-lease --force-if-includes
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #115

96. Сообщение от ptr (ok), 21-Апр-26, 23:24	+/–
>> C этим SVN справляется намного лучше. > И в чём лучшесть? Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком. > Гиту, на самом деле, вообще по барабану какие > данные трекать - с блобами он справляется также как с текстом, > с большими блобами так же как с маленькими. А Вы проверьте. Возьмите видеоролик размером хотя бы в несколько десятков мегабайт, наложите титры названия на начало, чтобы нужно перекодировать всего один-два фрейма от ключевого кадра до ключевого. Затем десять раз поправьте текст, шрифт или местоположение этих титров, делая после каждой корректировки commit. В результате репозиторий Git окажется почти на порядок большего размера, чем у SVN. > Когда говорят о бинарных данных, обычно имеют в виду что не хотят > хранить всю их историю локально. Откуда такие экстрасенсорные провидения? > Для этого есть LFS И как же она заменит систему контроля версий?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #113

97. Сообщение от OpenEcho (?), 21-Апр-26, 23:52	+/–
Cmon... `restic backup`, удобней :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

98. Сообщение от OpenEcho (?), 21-Апр-26, 23:57	+/–
> Можно подумать есть выбор. Ну вон sqlite вполне себе обходится fossil-scm, который по ходу all-in-one и трекер и форум и вики и SCM и всё в одном флаконе, а с "миром" (с гитом т.е.)  через импорт/экспорт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #111

99. Сообщение от Аноним (99), 22-Апр-26, 00:39	+/–
Была нормальной до того, как они женились на MalwareScript.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

100. Сообщение от Аноним (100), 22-Апр-26, 00:44	+/–
Если pull с авто-rebase (как оно и должно быть), то ничего не отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #124

102. Сообщение от Аноним (1), 22-Апр-26, 10:23	+/–
> За все эти годы эти фаны так и не удосужились сделать рормальную работу с PR Где сделать? Прям в ртути? А git'е оно как нормально сделано (именно в git-е, а не в гитхабе, гитлабе и тд)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

104. Сообщение от Аноним (1), 22-Апр-26, 10:25	+/–
Уж лучше got от OpenBSD, чем что-то от гугла... тем более на безопасном языке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

105. Сообщение от Аноним (-), 22-Апр-26, 12:31	+/–
> Особенно потрясающе там теги и субмодули были сделаны, с которыми никогда не > знаешь, в какую репу коммитишь. Да там для начала просто скачать новую версию мало-мальски крупного проекта - мучение и позор. Так что вот именно мотание между версиями - мучительно, медленно, требует перекачки половины интернета и занимает совершенно неадекватное время. И тут гит такой за несколько секунд мне запрошенную версию linux kernel - хренась, раскатывает как из пушки! Ну что, "система контроля версий" версии то надо было контролировать - вот как-то так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

107. Сообщение от Аноним (-), 22-Апр-26, 12:43	+/–
> Утрутся. Что вечно на SHA1 сидеть, или с километровыми блобами в репозитории, > закомиченных в него недоумками по началу, а потом только сообразившими, что > репозиторий именно из-за этого стал километровым? Таки можно и вечно сидеть. SHA1 вообще не столько секурити фич сколько техническая штука для построения цепочек. Для секурити фич есть gpg-подписи на тэги. А так - вы конечно можете понаделать фигни, потом порвать мозг даунстримам, только потом не удивляйтесь что вас считают толи мутной малварью, толи ненадежынм апстримом, толи мутным типом, толи просто неадекватным - и не хотят вообще иметь дел с таким апстримом. > Или в очень большом репозитории с многолетней историей - с репозиторием на > многие гига? Грохнуть историю девелопа - это самое глупое что вообще можно сделать. Зачем вам тогда git? В зипаре исходники отгружайте! А кому время даунлоада важно - он, таки, может git clone --depth=1 делать, представляете? > ./*.patch, не впервой, утрутся, чем репозиторий в таком жутком состоянии держать. В нормальных репо, нормальные люди - форспуш в основные ветки не практикуют в принципе. Я лично такое делаю только для веток с фичами, которые в процессе девелопа, там такое еще допустимо иногда. Потому что с ними мало кто синкался и отъезд ветки не такая большая проблема и импактит может пару продвинутых интересантов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

108. Сообщение от Аноним (-), 22-Апр-26, 12:48	+/–
> Почему-то ртуть на питончике клонирует репозитори мгновенно, а гит на сишке - > долго и нудно по объектику. Не имею никаких проблем с скоростью клонирования репо в гите. Ворочая штуками с линухкернел размером. Теперь попробуйте вообще поворочать чем-то таким в hg - и мы поговорим кто там и что нудно делает, у кого перфоманс - отстойный, и что и где не тормозит. Конечно в любом мало-мальски сложном софте всегда можно к чему-нибудь придраться. Но в среднем по больнице git обставил этого не тормозящего - как с куста. С бранчами эта хрень тоже делает что-то левое, в угоду каким-то необучахам с svn или типа того. А в гите бранчи и теги работают именно так как это и ожидается, без факапов и костылей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

109. Сообщение от Вася Пупкин (?), 22-Апр-26, 13:12	+/–
вытолкнули с hg, жалею и скучаю. приходиться жрать гит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

110. Сообщение от Вася Пупкин (?), 22-Апр-26, 13:13	+/–
что с ним надо делать, чтоб он тормозил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #112, #118

111. Сообщение от Аноним (38), 22-Апр-26, 15:16	+/–
sqlite обходится этой noдeлкoй потому что это noдeлкa того же автора (причём чсх контрибушоны он не принимает, т.е. флоу совместной разработки через fossil вообще не использует и даже не представляет насколько он ужасен). Больше никто её не использует. > а с "миром" (с гитом т.е.)  через импорт/экспорт Нет, импорт/экспорт это именно импорт/экспорт - одноразовое действо для переезда туда или оттуда. Это не синхронизация, с гитом там взаимодействовать полноценно не получится. Но понятно что контрибуторам ничего не останется кроме как делать экспорт в git, в git нормально разрабатываться и потом как-то слать обратно патч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #131

112. Сообщение от Аноним (38), 22-Апр-26, 15:16	+/–
Написать что-то сложнее hello, world.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

113. Сообщение от Аноним (38), 22-Апр-26, 15:24	+/–
> Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком. С большинством бинарных форматов в этом нет смысла, ибо они меняются целиком. Все форматы так или иначе сжимается, после сжатия изменённый файл будет отличаться целиком. > А Вы проверьте. Возьмите видеоролик размером хотя бы в несколько десятков мегабайт, наложите титры названия на начало, чтобы нужно перекодировать всего один-два фрейма от ключевого кадра до ключевого. Затем десять раз поправьте текст, шрифт или местоположение этих титров, делая после каждой корректировки commit. В результате репозиторий Git окажется почти на порядок большего размера, чем у SVN. Возможно это только до следующего gc. Если там действительно меняются только ключевые кадры, общие части схлопнутся дельта компрессией при создании pack'а. Я, в прочем, не понимаю зачем результат процессинга хранить в VCS. Хранится исходный ролик и настройки субтитров. А про хранение блобов речь больше про .psd, или .blend или вордовские документы, на худой конец. Там никаких дельт не будет впомине. > И как же она заменит систему контроля версий? Что значит заменит систему контроля версий? Это часть git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #116

114. Сообщение от Аноним (38), 22-Апр-26, 15:33	+/–
> Они и реплеят ударными темпами 100500 комитов на свое счастье. Внятно оформить свое счастье и ребэйзнуть на что-то более новое? Не, вы что, это слишком просто Что значит "реплеят" и в чём разница с "ребейзнуть"? Если ты про схлопнуть в один коммит, то нет, этого делать категорически не нужно. Вот, например, кейс - дерево портов. Поверх мастера живёт ветка с несколькими десятками коммитов, включая - локальные изменения в инфре портов для удобства разработки, не предназначенные для апстриминга - локальные патчи на чужие порты, также не предназначенные для апстриминга - недоделанные обновления своих и чужих портов в разработке - готовые изменения портов, которые ждут тестирования, или аппрува мантейнера, или аппрува на зависимости Это всё по понятным причинам в один коммит склеивать нельзя, и живёт это в `pull --rebase` (конечно же никаких мержей), и ребейзится действительно по ощущениями дольше чем должно. Ну типа коммитов 5 в секунду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #122

115. Сообщение от Аноним (38), 22-Апр-26, 15:37	+/–
Если пушишь ты один, то можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

116. Сообщение от ptr (ok), 22-Апр-26, 16:26	+/–
>> Тем, что при изменении бинарного файла сохраняет в репозитории и передаёт по сети только его изменившуюся часть, а не весь файл целиком. > С большинством бинарных форматов в этом нет смысла, ибо они меняются целиком. А считали как? Лёжа на диване по мухам на потолке? ))) У среднего пользователя на компе видеофайлы имеют в среднем на порядок больший объём, чем все остальные бинарные файлы вместе взятые. > Возможно это только до следующего gc. Если там действительно меняются только ключевые > кадры, общие части схлопнутся дельта компрессией при создании pack'а. Я же писал - проверьте. Не применяется дельта-компрессия в git к бинарным файлам более-менее приличного размера. Он тупо складывает их в LFS. > прочем, не понимаю зачем результат процессинга хранить в VCS. Хранится исходный > ролик и настройки субтитров. Потому что читать не умеете. Субтитры и титры названия ролика - очень даже разные вещи. Хотя могу предложить при редактировании "замедлить" или "ускорить" трехсекундный фрагмент. Я уже молчу про REDCODE или Apple ProRes с битрейтом в гигабиты, когда создание даже рекламного ролика может произвести сотню терабайт версий, если не выделять дельту в бинарных данных. > Что значит заменит систему контроля версий? Это часть git. Которая хранит каждую версию файла целиком, а не дельту. Про что и речь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #119

117. Сообщение от Аноним (74), 22-Апр-26, 17:11	+/–
> Наоборот, GitHub оказался просто ПЕРВОЙ единственной серьёзно, нормально, с душой, слепленной социалочкой для кодеров Очевидно, всяких форже ты не застал. Когда они были лидерами. У них был один недостаток. Они были не для git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #121

118. Сообщение от Аноним (-), 22-Апр-26, 17:19	+/–
> что с ним надо делать, чтоб он тормозил? Поворочать им проект чуть крупнее чем я и мой хелловорлд. Линух кернел в него загони с всеми ревизиями и посмотри как тебе ЭТО будет. А гиту нормально, фигли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

119. Сообщение от Аноним (-), 22-Апр-26, 17:21	+/–
> А считали как? Лёжа на диване по мухам на потолке? ))) > У среднего пользователя на компе видеофайлы имеют в среднем на порядок больший > объём, чем все остальные бинарные файлы вместе взятые. Вот только при изменении видеофайла он тоже чаще всего меняется - почти на 100%, от и до. И вообще - система контроля версий исходников - все же не CDN для доставки видео. Бывают всякие смежные кейсы иногда. Но они редкие и в целом решаемые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #125

120. Сообщение от Аноним (-), 22-Апр-26, 17:23	+/–
> GitLab - фигня какая то запутанная, тормозная и перегруженная - никогда там > ничего что надо не найти. Но на самом деле по своему крут для "большого" прожектманагемента. Если у тебя голимый патч - он конечно избыточен для этого. А если здоровый проект из кучи частей и проч - таки норм. Правда тормозной он конечно да. И барахла в нем много. В этом смысле если более лайтово хотелось - gogs-образные, типа gitea/forgejo/как их там (деривативы gogs) явно лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

121. Сообщение от Аноним (-), 22-Апр-26, 17:24	+/–
> Очевидно, всяких форже ты не застал. Когда они были лидерами. У них > был один недостаток. Они были не для git. Они были - бесплатным хостингом для виндоблобов и характерными девами с CVS и SVN. За что и пострадали. Нормальные девелоперы выбрали git - а даунлоады они и сами себе нарулить с этим своим linux могут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117

122. Сообщение от Аноним (-), 22-Апр-26, 17:26	+/–
> Что значит "реплеят" и в чём разница с "ребейзнуть"? Если ты про > схлопнуть в один коммит, то нет, этого делать категорически не нужно. Ребэйз это и есть - реплей цепочки. Гит сперва добавит новые комиты в цепочку, потом поверх этого - если прокатило - ваши патчи. Но ума сэйвануть это состояние как новое у господ явно не хватило - и они на правах ритуала реапплаят 100500 патчей каждый раз. Ну можно и так. Только это не гит виноват...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

123. Сообщение от Аноним (-), 22-Апр-26, 17:31	+/–
> Сразу скажу: мне нужно отдельными коммитами, сквошить их в один я не стану. Ну так ребэйзни свой бранч с ними или что там у тебя на более новую версию апстрима - и число комитов которые надо аплаить при rebase радикально скостится. Да, коенчно если это делать раз в сто лет - и апстрим активный и навалит патчей - их реплей по цепочке станет занимать энное время. Просто дельту не стоит сильно отращивать и свои фичи ребейзить на актуальные комиты апстрима периодически. А не раз в сто лет или с продолбом результата этого и реаплаем каждый раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

124. Сообщение от Аноним (-), 22-Апр-26, 17:35	+/–
> Если pull с авто-rebase (как оно и должно быть), то ничего не > отъедет. Спокойненько выполнится rebase твоих локальных коммитов на новый HEAD, и всё. Да вот понимаешь ли, я могу чисто технически сделать push --force чего-то совсем радикально иного - на что ремоты - таки - десинхронизируются. И обучать их там всех правильно пул делать - ну тоже такое себе. Пожтому лично я push --force практикую только для мелких фич in flight с 1-3 интересантами. Если это не оно я подумаю о альтернативах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

125. Сообщение от ptr (ok), 22-Апр-26, 17:53	+/–
> Вот только при изменении видеофайла он тоже чаще всего меняется - почти > на 100%, от и до. Вы очень плохо знаете форматы видеофайлов. Ещё с MPEG-1 модификация видеофайла не требовала перекодирования незатронутых изменениями блоков. Перекодировка требуется от предыдущего до измененного участка ключевого кадра до следующего за этим участком ключевого кадра. Причём в профессиональных форматах видеокодирования, начиная с MJPEG, все кадры ключевые, что позволяет перекодировать только модифицированные кадры. > система контроля версий исходников Именно так. Как и написано в заголовке, git - система управления исходными ТЕКСТАМИ. На эффективную  работу с бинарными файлами он не расчитан. Что я и указал изначально. Он не может быть "лучшей системой контроля версий", так как расчитан, в первую очередь, на ТЕКСТЫ, а не на любые данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

126. Сообщение от Аноним (126), 22-Апр-26, 17:57	+/–
Гит обрастает хламом. С каждым новым релизом он всё дальше от бога. Идеал — когда нечего убрать и все рабочие потребности закрыты полностью. Гит идет обратной дорогой — наваливает все больше функций, а свою основную работу делает кое-как (не надо делать вид, что сломанная репа это целиком вина разработчика). Вот в коментах упоминают Ртуть. Она почти мертва и мало кем используется, но при этом в ней есть всё что нужно для работы.  Я пользуюсь ей для своих проектов. Ртуть ни разу не делала мне голову в отличии от гита. Всё таки смерть — это настояший релиз программы. Миллионы мух летят дальше на новый релиз более модной технологии, а ты ценишь покой, когда в "умершей" программе всё изучено и работает без суеты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #130, #132

127. Сообщение от Аноним (38), 22-Апр-26, 18:36	+/–
Ну субмодули, справедливости ради, именно для этого и были сделаны - прозрачно коммитить в другую репу, и в git они работают так же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

128. Сообщение от Аноним (38), 22-Апр-26, 18:39    Скрыто ботом-модератором	+/–
Нет, я не сравниваю. Но тут остались ещё утятки которые никак hg забыть не могут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

129. Сообщение от Аноним (38), 22-Апр-26, 18:43	+/–
> Например, его более бережное отношение к истории. Бережное отношение к истории - это сделать фичу, разбить её на topic коммиты отражающие стадии её внедрения и в таком виде влить. Те кто считают "бережным отношением к истории" необходимость фиксировать всю промежуточную работу, включая несобирающийся код, debug принты, закоммиченные по ошибке секреты и выходные файлы, не закоммиченные по ошибке исходники, к индустрии никакого отношения, действительно, не имеют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

130. Сообщение от Гуманоид (?), 23-Апр-26, 01:45	+/–
Аналогично, для себя только ртуть. Меркуриал сделан для людей. Git сделан для погромистов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

131. Сообщение от Прохожий (??), 23-Апр-26, 02:33    Скрыто ботом-модератором	+/–
>даже не представляет насколько он ужасен Например, чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

132. Сообщение от Аноним (132), 23-Апр-26, 06:57	+/–
Любой пень в лесу обрастает грибами, это абсолютно нормальное явление, git add --all && git commit -am "Update" && git push - работает много лет и ниразу ничего не ломал, так же как и многие другие команды, и никакой суеты, беспонятия какие версии гитов где стоят. > когда в "умершей" программе Вот ключевое, когда будущего большего нет, когда наплевать как оно там будет потом, типа на мой век еще хватит, а дальше пофиг, это называется старость, я сам далеко не молод, но не считаю, что надо сидеть на 486 с коаксильной сетевухой 3com и гундеть о том что раньше было лучше, для тебя было, а для молодежи не было. Пусть пилят, пусть выпиливают хлам, теперь это их мир, пройдет время и их хлам выпилят, таков путь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема