Re[6]: Почему некотрые идио... люди агитируют за Mercurial? - Компьютерные священные войны

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Допустим ещё нет ни одной и надо выбрать, какую использовать в команде. Один "лидер" за mercurial, другие люди за git. Что делать с первым?

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

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

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>https://stackshare.io/stackups/git-vs-mercurial

"А судьи кто?" (c). Понятно, что сейчас все новички сразу садятся на git и смысла изучать что-то другое нет — так что и процент голосов вполне себе объясним. А так оно работало нормально ещё тогда, когда на git без слёз взглянуть было невозможно. Особенно под виндой.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

ЭФ>https://stackshare.io/stackups/git-vs-mercurial

Ну, есть, например, аспекты конкуренции. Чем сложнее и бестолковее инструмент, тем больше я выиграю, если мои конкуренты его изучат. Я не знаю, как это относится конкретно к Mercurial, но принцип универсальный.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

ЭФ>https://stackshare.io/stackups/git-vs-mercurial
Меркуриал удобнее и очевиднее использовать через черепашку, гит из командной строки. В остальном Т.к. я командную строку и прочие извращения на ее основе (типа вима) ненавижу, то в коммандах которых руководил было правило --если всем пофиг, то меркуриал, если найдется три человека, которым не пофиг, то гит. В остальном они практически взаимозаменяемы, точно можно тянуть и толкать hg из гитовой репы и почти наверняка можно наоборот.

ЭФ>Ну ясно же видно
Отнюдь.
Лично я гит терпеть не могу за весьма нетрадиционные подходы.
Инструмент хранения кода не должен мне говорить, как мне вести разработку.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

ЭФ>https://stackshare.io/stackups/git-vs-mercurial

Я __сейчас__ не за кого не агитирую, но могу объяснить почему я агитировал на хг пару лет назад:
Самый популярный гуи клиент под гит (гит экстеншн) выдал мне AV при работе в гит хз хабом. Не сейчекс, пару лет назад. Но тортоисхг не позволял такого.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

А я просто SVN использую...

J> Самый популярный гуи клиент под гит (гит экстеншн) выдал мне AV при работе в гит хз хабом.

Он опенсорсный, ты мог бы и сам пофиксить...

Здравствуйте, Эйнсток Файр, Вы писали:

Мы используем Mercurial на работе.
Из реальных плюсов: людей достаточно легко обучить основам и есть один нормальный интерфейс в виде TortoiseHG.
Труднее накосячить, я нередко слышал от друзей как новички пользуются Git-ом и портят историю, push --force без разбора.
В средах от JetBrains разница между системами контроля версий вообще нивелируются.

Из минусов: MS ~~GitHub~~ Некоторые забили на него и поддерживают только Git, а посему без знания Git-а продвинутым людям никуда не деться ну или всё делать исключительно из IDE.
И Git намного быстрее работает в огромных проектах.

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>>Ну ясно же видно, что у него никаких перспектив:

ARK>А я просто SVN использую...

Нет причин использовать SVN, если это не FreeBSD Source. Для индивидуалистов есть Fossil SCM.

Здравствуйте, _NN_, Вы писали:

_NN>И Git намного быстрее работает в огромных проектах.

Что не мешало использовать Mercurial для разработки OpenJDK и Mozilla.

Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, _NN_, Вы писали:

_NN>>И Git намного быстрее работает в огромных проектах.

ZEN>Что не мешало использовать Mercurial для разработки OpenJDK и Mozilla.

Мне тоже особо не мешает.
Но таки переписывать будут: https://www.mercurial-scm.org/wiki/OxidationPlan

Здравствуйте, iZEN, Вы писали:

ARK>>А я просто SVN использую...

ZEN>Нет причин использовать SVN, если это не FreeBSD Source.

Почему?

Здравствуйте, AlexRK, Вы писали:

iZEN>>Нет причин использовать SVN, если это не FreeBSD Source.

ARK>Почему?

Потому: https://habrahabr.ru/post/177451/

Здравствуйте, AlexRK, Вы писали:

ARK>А я просто SVN использую...

Вот, кстати, учебник для перехода с SVN на Mercurial: https://habrahabr.ru/post/108443/

Здравствуйте, iZEN, Вы писали:

iZEN>>>Нет причин использовать SVN, если это не FreeBSD Source.

ARK>>Почему?

ZEN>Потому: https://habrahabr.ru/post/177451/

Не увидел в этой статье, почему нет причин использовать SVN. Предлагаются сомнительные (для меня, во всяком случае) преимущества за счет увеличения сложности.

Здравствуйте, iZEN, Вы писали:

ARK>>А я просто SVN использую...

ZEN>Вот, кстати, учебник для перехода с SVN на Mercurial: https://habrahabr.ru/post/108443/

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

Здравствуйте, _NN_, Вы писали:

_NN>Мне тоже особо не мешает.
_NN>Но таки переписывать будут: https://www.mercurial-scm.org/wiki/OxidationPlan

Обоснования необходимости местами выглядят странно, запуск 250мс (в сравнении с 10мс у git) — может я как-то не так систему контроля версий использую, но обычно это совершенно не мешает — git запускается для коммитов и синхронизации, и на фоне продолжительности синхронизации 250мс не то что бы много.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

Вкусовщина лидеров команды. Я работаю в Visual Studio, там есть нормальная поддержка из коробки двух систем: TFS и Git. Значит, использую их — чем меньше мне надо думать о системе контроля версий, тем лучше. Я должен в студии видеть список изменённых файлов, их историю, сравнивать код, делать откаты и игноры. Я занят написанием кода в студии, ковыряться в командной строке или сторонних программах времени нет. Поэтому Mercurial отправляется в топку вместе с другими системами, которые не имеют поддержки в студии и мешают мне писать код, заставляя прерываться на возню с ними. Технические преимущества разных систем абсолютно несущественны в типичных проектах писанины софта на заказ.

Если я сижу в FreeBSD, где нет никакой студии, то я использую SVN — это просто и понятно, не тормозит меня в работе. И никакой Git не нужен.

Здравствуйте, Vladek, Вы писали:

V>Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>>Ну ясно же видно, что у него никаких перспектив:

V>Вкусовщина лидеров команды. Я работаю в Visual Studio, там есть нормальная поддержка из коробки двух систем: TFS и Git. Значит, использую их — чем меньше мне надо думать о системе контроля версий, тем лучше. Я должен в студии видеть список изменённых файлов, их историю, сравнивать код, делать откаты и игноры. Я занят написанием кода в студии, ковыряться в командной строке или сторонних программах времени нет.

Я для себя использую Mercurial. И хотя им можно пользоваться из Студии

почему-то предпочитаю отдельный родной клиент TortoiseHg

То ли потому что в Студии и так очень много лишних ручек и кнопочек, а в клиенте всё что относится к контролю версий отделено от Студии и собрано в одном месте. То ли потому что TortoiseHg такой удобный ― пробовал другие клиенты (SourceTree и SmartGit/Hg), но как-то не пошли.

Здравствуйте, alexzzzz, Вы писали:

A>То ли потому что в Студии и так очень много лишних ручек и кнопочек, а в клиенте всё что относится к контролю версий отделено от Студии и собрано в одном месте. То ли потому что TortoiseHg такой удобный ― пробовал другие клиенты (SourceTree и SmartGit/Hg), но как-то не пошли.

А я всё это время писал код в студии, крутя ручки и нажимая кнопочки, и не парился с клиентами.

Мне удобно всё делать из студии, иначе ощущение контроля над ситуацией пропадает.

Здравствуйте, AlexRK, Вы писали:

ARK>Не увидел в этой статье, почему нет причин использовать SVN. Предлагаются сомнительные (для меня, во всяком случае) преимущества за счет увеличения сложности.

С ветками работал? В общем случае после слияния ветки обратно в SVN с историй было не очень, насколько я помню. Поэтому я в своё время не мёржил обратно ветку, а накатывал патч с ветки на мастера и так заливал.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

Если глаза у тебя где-то возле *опы, то идиот тут скорее ты сам.
Меркуриал — это вещь, которую проектировали. Git — это перделка Трольвадса для облегчения себе работы, отсюда и такое похабное качество и юзабилити.

Единственная причина, приходящая на ум, это наличие TourtoiseHG Workbench. Отличный гуй, хотел бы такой к гиту. Всем, кто имеет у себя удобную консоль (линукс, макос, вероятно wsl), и с ней на "ты" — это не так критично. Меня лично бесит HG, гит удобней

Здравствуйте, alexzzzz, Вы писали:

А почему не VisualHG, который совмещает эти два удобства ?

https://github.com/geoffappleford/VisualHG2015/releases/tag/3.0.1.2

Здравствуйте, AlexRK, Вы писали:

ARK>Не увидел в этой статье, почему нет причин использовать SVN. Предлагаются сомнительные (для меня, во всяком случае) преимущества за счет увеличения сложности.

Мне достаточно следующих причин:
1. SVN не работает в оффлайне. Интернет, конечно, есть всегда и везде. Но он имеет подлую привычку ломаться именно тогда, когда его поломка критична (например, прямо перед важным релизом). А не интернет, так сервер, на котором крутится SVN.
2. Меркурий (git и проч.) очень легко разворачивается ad-hoc. SVN требует сначала настроить сервер, завести репозиторий, настроить права доступа,...
3. У SVN нет меток и бранчей

Здравствуйте, iZEN, Вы писали:

ZEN>Вот, кстати, учебник для перехода с SVN на Mercurial: https://habrahabr.ru/post/108443/

У меркурия большая часть команд совпадает с SVN'овскими (а точнее, с CVS'овскими, который их общий предок)

Здравствуйте, _NN_, Вы писали:

_NN>Из минусов: MS ~~GitHub~~ Некоторые забили на него и поддерживают только Git, а посему без знания Git-а продвинутым людям никуда не деться ну или всё делать исключительно из IDE.

Можно работать из меркурия с гитовским репозиторием с помощью специального плагина

_NN>И Git намного быстрее работает в огромных проектах.

Ну я бы не сказал...

Здравствуйте, Somescout, Вы писали:

S>Обоснования необходимости местами выглядят странно, запуск 250мс (в сравнении с 10мс у git) — может я как-то не так систему контроля версий использую, но обычно это совершенно не мешает — git запускается для коммитов и синхронизации, и на фоне продолжительности синхронизации 250мс не то что бы много.

Куда это они его запускают за 250мс. У меня на проекте среднего размера hg status успевает за 140мс полностью отработать...

Здравствуйте, _NN_, Вы писали:

_NN>А почему не VisualHG, который совмещает эти два удобства ?

А не помню. Точно помню, что я его видел и пробовал, и он был внешне вроде посимпатичнее HgScc, но то ли в нём было какое-то неудобство для меня, то ли не было версии под свежую Студию. В общем, вернулся на использование внешнего клиента TortoiseHg и плагина HgScc, который просто в Студии стоит, но я практически не пользуюсь его функционалом.

Надо ещё раз попробовать VisualHG.

Здравствуйте, Pzz, Вы писали:

Pzz>Можно работать из меркурия с гитовским репозиторием с помощью специального плагина

Причём встроенного, по крайней мере, в TortoiseHg. Использую эту возможность, чтобы поковыряться руками в любопытных мне репозиториях на GitHub. При клонировании из GitHub к себе в Mercurial к адресу исходного репозитория дописываю спереди "git+" и всё работает, включая большие репозитории типа Mono или CoreFX.

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

Допустим, мы вдвоём с товарищем пушим/пулим в общий репозиторий Git. Только он это делает из своего Git, а я из Hg. У нас точно ничего не поломается и не перепутается? Нужно ли заранее вырабатывать какие-нибудь правила работы, чтобы не перепуталось?

Здравствуйте, alexzzzz, Вы писали:

A>Допустим, мы вдвоём с товарищем пушим/пулим в общий репозиторий Git. Только он это делает из своего Git, а я из Hg. У нас точно ничего не поломается и не перепутается? Нужно ли заранее вырабатывать какие-нибудь правила работы, чтобы не перепуталось?

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

Единственное, что я заметил, у нас репозитории были на гитхабе, и вот если работать через https, то в какой-то момент что-то ломалось, и становилось невозможным запушить свои изменения. При работе через ssh (гитхаб умеет и так и так) таких проблем никогда не возникало.

Ну и вторая проблема, первоначальный clone выполнается ОЧЕНЬ медленно. Дальше все ОК.

Здравствуйте, Pzz, Вы писали:

Pzz>Я работал в некоей команде в качестве приграшенного специалиста некоторое время в таком режиме, проблем никаких не возникало.

Я просто боюсь устроить нечаянный саботаж.

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

И Hg в общем-то плевать, как именно ты предпочитаешь ветвиться, он переваривает всё. Единственно, при пуше новой неименованной головы может предупредить, что так поступать некрасиво; но это предупреждение ни к чему не обязывает.

При клонировании Git-репозитория в Hg, если не ошибаюсь, Git-ветки превращаются в Hg-закладки, как наиболее близкое по смыслу. Интересно, что произойдёт, если случайно попытаться запушить из Hg в Git новую ветку с новым именем или новую неименованную голову в существующей именованной ветке и не назначить им закладок/bookmarks? Надеюсь, что Hg не даст этого сделать, но сам не пробовал.

Здравствуйте, Pzz, Вы писали:

Pzz>3. У SVN нет меток и бранчей
В svn конечно много чего нет но это вот без проблем. Не такие может халяльные, как у православных.

Здравствуйте, GarryIV, Вы писали:

Pzz>>3. У SVN нет меток и бранчей
GIV>В svn конечно много чего нет но это вот без проблем. Не такие может халяльные, как у православных.

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

Здравствуйте, Pzz, Вы писали:

Pzz>>>3. У SVN нет меток и бранчей
GIV>>В svn конечно много чего нет но это вот без проблем. Не такие может халяльные, как у православных.

Pzz>В SVN нет меток и бранчей. Авторы SVN объясняют это тем, что у них такое крутое клонирование директорий, что метки и бранчи никому не нужны.

Ну и я говорю, не халяльные там они.

Здравствуйте, Pzz, Вы писали:

Pzz>Мне достаточно следующих причин:
Pzz>1. SVN не работает в оффлайне. Интернет, конечно, есть всегда и везде. Но он имеет подлую привычку ломаться именно тогда, когда его поломка критична (например, прямо перед важным релизом). А не интернет, так сервер, на котором крутится SVN.

А зачем нужна работа в оффлайне? Ну нет интернета, и фиг с ним. Закоммичу, когда появится.

Pzz>2. Меркурий (git и проч.) очень легко разворачивается ad-hoc. SVN требует сначала настроить сервер, завести репозиторий, настроить права доступа,...

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

Pzz>3. У SVN нет меток и бранчей

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

Здравствуйте, AlexRK, Вы писали:

Pzz>>1. SVN не работает в оффлайне. Интернет, конечно, есть всегда и везде. Но он имеет подлую привычку ломаться именно тогда, когда его поломка критична (например, прямо перед важным релизом). А не интернет, так сервер, на котором крутится SVN.
ARK>А зачем нужна работа в оффлайне? Ну нет интернета, и фиг с ним. Закоммичу, когда появится.

А затем, чтобы фиксировать сделанное и иметь checkpoint для движения дальше.
(И не делать это суперпуперVCS 80-х годов в виде кнопки F5 на каталоге.)

Здравствуйте, netch80, Вы писали:

Pzz>>>1. SVN не работает в оффлайне. Интернет, конечно, есть всегда и везде. Но он имеет подлую привычку ломаться именно тогда, когда его поломка критична (например, прямо перед важным релизом). А не интернет, так сервер, на котором крутится SVN.
ARK>>А зачем нужна работа в оффлайне? Ну нет интернета, и фиг с ним. Закоммичу, когда появится.

N>А затем, чтобы фиксировать сделанное и иметь checkpoint для движения дальше.
N>(И не делать это суперпуперVCS 80-х годов в виде кнопки F5 на каталоге.)

А что страшного произойдет, если я зафиксирую сделанное через два часа?

Здравствуйте, _NN_, Вы писали:

_NN>Труднее накосячить, я нередко слышал от друзей как новички пользуются Git-ом и портят историю, push --force без разбора.

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

Здравствуйте, AlexRK, Вы писали:

Pzz>>>>1. SVN не работает в оффлайне. Интернет, конечно, есть всегда и везде. Но он имеет подлую привычку ломаться именно тогда, когда его поломка критична (например, прямо перед важным релизом). А не интернет, так сервер, на котором крутится SVN.
ARK>>>А зачем нужна работа в оффлайне? Ну нет интернета, и фиг с ним. Закоммичу, когда появится.

N>>А затем, чтобы фиксировать сделанное и иметь checkpoint для движения дальше.
N>>(И не делать это суперпуперVCS 80-х годов в виде кнопки F5 на каталоге.)

ARK>А что страшного произойдет, если я зафиксирую сделанное через два часа?

Коммит это не кнопка "сохранить на сервер", это атомарное логическое изменение кода. За два часа можно сделать 20 коммитов.

Здравствуйте, vsb, Вы писали:

ARK>>А что страшного произойдет, если я зафиксирую сделанное через два часа?

vsb>Коммит это не кнопка "сохранить на сервер", это атомарное логическое изменение кода. За два часа можно сделать 20 коммитов.

Ясно. Лично я таким не занимаюсь и не вижу в этом необходимости.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, _NN_, Вы писали:

_NN>>Труднее накосячить, я нередко слышал от друзей как новички пользуются Git-ом и портят историю, push --force без разбора.

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

Я в курсе.
Однако расскажите где так делают, обычно никто не делает.
Тот же GitHub не запрещает.

Здравствуйте, AlexRK, Вы писали:

Pzz>>>>1. SVN не работает в оффлайне. Интернет, конечно, есть всегда и везде. Но он имеет подлую привычку ломаться именно тогда, когда его поломка критична (например, прямо перед важным релизом). А не интернет, так сервер, на котором крутится SVN.
ARK>>>А зачем нужна работа в оффлайне? Ну нет интернета, и фиг с ним. Закоммичу, когда появится.

N>>А затем, чтобы фиксировать сделанное и иметь checkpoint для движения дальше.
N>>(И не делать это суперпуперVCS 80-х годов в виде кнопки F5 на каталоге.)

ARK>А что страшного произойдет, если я зафиксирую сделанное через два часа?

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

Мне лично времени жалко на ерунду, коммит — дело пары секунд.

Здравствуйте, netch80, Вы писали:

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

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

N>И в результате ты будешь копаться в куче разнородных правок, что надо сохранять, а что нет, в каком варианте работает и почему... и убьёшь на это ещё три часа.

Все пять раз это было просто Ctrl+Z за несколько секунд.

N>Мне лично времени жалко на ерунду, коммит — дело пары секунд.

За неделю из этих двух секунд набежит два часа.

Здравствуйте, _NN_, Вы писали:

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

_NN>Я в курсе.
_NN>Однако расскажите где так делают, обычно никто не делает.
_NN>Тот же GitHub не запрещает.

В GitHub вроде через protected branch делается, т.е. одной галочкой. По-мне надо по умолчанию такое запрещать, а разрешать только с большими ругательствами и вызовом ~~родителей~~ администратора, но и так не сложно.

Здравствуйте, vsb, Вы писали

_NN>>Я в курсе.
_NN>>Однако расскажите где так делают, обычно никто не делает.
_NN>>Тот же GitHub не запрещает.

vsb>В GitHub вроде через protected branch делается, т.е. одной галочкой. По-мне надо по умолчанию такое запрещать, а разрешать только с большими ругательствами и вызовом ~~родителей~~ администратора, но и так не сложно.
Но не все это делают.

Я лично считаю, что и merge —no-ff по умолчанию должен быть , однако в гит нельзя идти таким путём.
Очередная фишка это неименованые ветки, которые к тому же можно запросто удалить и иди разберись в истории.

Здравствуйте, AlexRK, Вы писали:

N>>И в результате ты будешь копаться в куче разнородных правок, что надо сохранять, а что нет, в каком варианте работает и почему... и убьёшь на это ещё три часа.

ARK>Все пять раз это было просто Ctrl+Z за несколько секунд.

Твоя IDE позволяет общую историю на несколько разных файлов, которую можно откатывать через Ctrl+Z?
Если да — назови её. Если нет — извини, работа, когда всегда меняется только один файл, это уровень детской песочницы, по сравнению с тем, для чего вообще разрабатываются SCM системы типа git.

N>>Мне лично времени жалко на ерунду, коммит — дело пары секунд.
ARK>За неделю из этих двух секунд набежит два часа.

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

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

ARK>Ну, может раз пять за всю жизнь у меня такое и было. Но вообще это ужасно редкий кейс.

Честно завидую такой простоте. Для таких задач годится любая SCM, хоть древняя пофайловая RCS, хоть неуклюжая SourceSafe, хоть вообще кнопка F5 на архивный диск.

Здравствуйте, netch80, Вы писали:

N>Твоя IDE позволяет общую историю на несколько разных файлов, которую можно откатывать через Ctrl+Z?
N>Если да — назови её.

Ну да, Visual Studio. Undo global action.

N>Да. И на них надо отвлекаться не только потому, что это точка отката — но и потому, что осознание сделанного является необходимым для движения вперёд.

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

N>Честно завидую такой простоте. Для таких задач годится любая SCM, хоть древняя пофайловая RCS, хоть неуклюжая SourceSafe, хоть вообще кнопка F5 на архивный диск.

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

Здравствуйте, AlexRK, Вы писали:

ARK>Ну, может раз пять за всю жизнь у меня такое и было. Но вообще это ужасно редкий кейс.

С рефакторингом не экспериментируете? Я выкидываю результаты экспериментов примерно пару раз в неделю.

ARK>Все пять раз это было просто Ctrl+Z за несколько секунд.

Я раньше тоже так делал. Очень огорчало, когда Visual Studio 2017 наглухо висла и часть удаленного кода приходилось писать заново — после перезапуска Ctrl+Z уже не помогает.

N>>Мне лично времени жалко на ерунду, коммит — дело пары секунд.
ARK>За неделю из этих двух секунд набежит два часа.

Коммит делают чтоб сохранить состояние. Если вам оно не нужно — никто ж не заставляет тратить время на сохранения.

Здравствуйте, vsb, Вы писали:

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

когда строчишь мелкие коммиты по задаче, в конце удобно их слепить в один.
тут-то и происходит изменение истории, которое потребует `push -f`

Здравствуйте, netch80, Вы писали:

N>Твоя IDE позволяет общую историю на несколько разных файлов, которую можно откатывать через Ctrl+Z?
N>Если да — назови её.

idea же хранит свою историю правок файлов.
пару раз помогало.

Здравствуйте, neFormal, Вы писали:

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

F>когда строчишь мелкие коммиты по задаче, в конце удобно их слепить в один.
F>тут-то и происходит изменение истории, которое потребует `push -f`

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

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, neFormal, Вы писали:

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

F>>когда строчишь мелкие коммиты по задаче, в конце удобно их слепить в один.
F>>тут-то и происходит изменение истории, которое потребует `push -f`

vsb>Просто не надо их пушить, пока не закончил.

а если ты не один с этим работаешь? такие ситуации бывают при активном прототипировании
или может хочешь из дома с этим поработать
или уходишь домой и параноишь относительно отказа винта

vsb>Если хочешь пушить — заведи отдельную ветку на сервере, пушь в неё, а потом смерджь в мастер одним коммитом (правда я так не делал, но проблемы быть не должно).

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

Здравствуйте, neFormal, Вы писали:

vsb>>Просто не надо их пушить, пока не закончил.

F>а если ты не один с этим работаешь? такие ситуации бывают при активном прототипировании
F>или может хочешь из дома с этим поработать

Ну тогда сам бог велел отдельную ветку создавать.

F>или уходишь домой и параноишь относительно отказа винта

А насчёт отказа винта на сервере не параноишь?

vsb>>Если хочешь пушить — заведи отдельную ветку на сервере, пушь в неё, а потом смерджь в мастер одним коммитом (правда я так не делал, но проблемы быть не должно).

F>то же самое, только с другими приседаниями.

Разница принципиальна. При запрете force push данные из репозитория потерять почти невозможно. С force push данные потерять тривиально.

F>только диффы смотреть неудобно при ревью

В чём разница? Так же будет один коммит.

Здравствуйте, vsb, Вы писали:

vsb>>>Просто не надо их пушить, пока не закончил.
F>>а если ты не один с этим работаешь? такие ситуации бывают при активном прототипировании
F>>или может хочешь из дома с этим поработать
vsb>Ну тогда сам бог велел отдельную ветку создавать.

я только указал, что это рабочий путь.

F>>или уходишь домой и параноишь относительно отказа винта
vsb>А насчёт отказа винта на сервере не параноишь?

нет, это ж не svn. копия уже минимум в двух местах.

vsb>>>Если хочешь пушить — заведи отдельную ветку на сервере, пушь в неё, а потом смерджь в мастер одним коммитом (правда я так не делал, но проблемы быть не должно).
F>>то же самое, только с другими приседаниями.
vsb>Разница принципиальна. При запрете force push данные из репозитория потерять почти невозможно. С force push данные потерять тривиально.

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

F>>только диффы смотреть неудобно при ревью
vsb>В чём разница? Так же будет один коммит.

это после мержа. ревью делается до.

Здравствуйте, neFormal, Вы писали:

F>это ты просто не умеешь искать коммиты, на которые нет ссылки из публичных веток.
F>до пуржа и т.п. вещей можно всё достать.

Ну так-то можно и с диска найти, пока не перезаписались блоки

Здравствуйте, vsb, Вы писали:

F>>до пуржа и т.п. вещей можно всё достать.
vsb>Ну так-то можно и с диска найти, пока не перезаписались блоки

Проблема push -f в первую очередь с теми, кто не умеет пользоваться Git-ом. И рассчитывать, что они потом найдут свои данные, имхо, наивно. Хорошо, если в команде найдётся гуру, а скорей всего будут просто перебивать всё заново, поставив галочку у себя в голове: "Git ненадёжный". Это реальный аргумент в пользу меркуриала, который я слышал, когда люди теряют данные после как им кажется простых действий.

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

F>>>>только диффы смотреть неудобно при ревью
vsb>>>В чём разница? Так же будет один коммит.
F>>это после мержа. ревью делается до.
vsb>ревьюится пулл-реквест в мастер обычно, вот этот пулл-реквест и сделай объединением всех коммитов.

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

Здравствуйте, netch80, Вы писали:

N>Твоя IDE позволяет общую историю на несколько разных файлов, которую можно откатывать через Ctrl+Z?
N>Если да — назови её.

IntelliJ Idea.

Единственное через Ctrl+Z удобно только если недавние изменения, иначе рулит Local History.

Что сейчас-то в 2022-м году минусы ставить? Прав я был кругом.

Здравствуйте, iZEN, Вы писали:

ZEN>Нет причин использовать SVN, если это не FreeBSD Source. Для индивидуалистов есть Fossil SCM.

Есть причина. Это — централизованное управление версиями. С блокировкой файлов.

rm2>Есть причина. Это — централизованное управление версиями. С блокировкой файлов.

Что значит централизованное управление версиями?

Здравствуйте, Somescout, Вы писали:

S>А при чём тут "перспективы"? Есть плюсы и минусы использования, и из очень хороших плюсов — то что это единый инструмент, а не свалка утилит как git, для запуска которого чуть ли не полноценный Cygwin (или WSL) нужен. В остальном — вообще не вижу смысла ср*ться за систему контроля версий (если она соответствует требованиям).

Да вроде попроще, как-то без цугвина обхожусь

Здравствуйте, DiPaolo, Вы писали:

DP>Что значит централизованное управление версиями?

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

DP>>Что значит централизованное управление версиями?

rm2>Один централизованный репозиторий. Блокируешь файл, и все, никто уже в него не залезет, пока ты не завершишь работу, что исключает конфликты в стиле "два работника изменили одно и тоже место каждый по своему".

Это, скорее, централизованное управление блокировками.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:

С Git я всё время лезу в справку, чтобы выяснить кто есть кто (ours и theirs) при merge и rebase, потому что в одной из этих двух операций понятия перепутаны. Это бесит жутко. Я понимаю, что у авторов там своя логика была, но подозреваю, что основана она была на унификации при кодировании, а не с человеческой точки зрения.

Здравствуйте, rm2, Вы писали:

DP>>Что значит централизованное управление версиями?

rm2>Один централизованный репозиторий. Блокируешь файл, и все, никто уже в него не залезет, пока ты не завершишь работу, что исключает конфликты в стиле "два работника изменили одно и тоже место каждый по своему".

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

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

Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, netch80, Вы писали:

N>>Твоя IDE позволяет общую историю на несколько разных файлов, которую можно откатывать через Ctrl+Z?
N>>Если да — назови её.

ARK>Ну да, Visual Studio. Undo global action.

Одна global action. А так, чтобы по Ctrl+Z оно переходило само в другой файл и отменяло правку в нём, потому что она была по времени ровно на одну перед?

Здравствуйте, cppguard, Вы писали:

C>С Git я всё время лезу в справку, чтобы выяснить кто есть кто (ours и theirs) при merge и rebase, потому что в одной из этих двух операций понятия перепутаны. Это бесит жутко. Я понимаю, что у авторов там своя логика была, но подозреваю, что основана она была на унификации при кодировании, а не с человеческой точки зрения.

Там в `git help rebase` объяснено, какими именно человеческими соображениями они руководствовались. Если подумать, то они вполне правы.

Здравствуйте, netch80, Вы писали:

N>А потом тот, кому твоя блокировка мешает, создаёт новую ветку (в SVN — каталог репы) как копию той, что ты заблокировал, пишет туда свои изменения, приходит к начальству "я тут супер пупер фичу забабахал, а меня не пускают", начальство даёт тебе по голове, снимает твою блокировку и мержит его версию.

Нет. Они сидят и ждут (но чаще всего работа распределяется таким образом, чтобы никто не пересекался по файлам). А вот попытка создания ветки, да, приводит к ударам по головам.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Почему некотрые люди агитируют за Mercurial?

Профессионально использую как Git, так и Mercurial. От шероховатостей и непродуманостей первого, простите, блевать порою хочется.

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

Использовать Git вместо Mercurial — это то же самое, что продолжать использовать CVS вместо SVN. Это родственные системы, делают одно и то же, одинаковым способом, но есть серьезные отличия в usability. Если попробовать их использовать на практике, то будет приблизительно такой расклад: у CVS операции все на ручнике, непродуманные, можно легко упороть репозиторий в плохое состояние, из которого потом трудно выйти; а у SVN все очень натуральное, хорошо визуализировано, понятные человеческие концепции, относительно простые и доступные операции. Да, делают они одно и то же, сходным способом. А теперь представьте себе мир извращенцев, которые до сих пор массово сидят на CVS. Это нормальные люди? Нет. Это либо неадекваты, либо заложники тулинга, либо несчастные рабы на потогонках, где приказано использовать соху и мотыгу в эпоху механизации.

Но откуда вам это это всё знать, если вы сразу вылупились в Git инкубаторе? Курица не улетит из своего уютного курятника, она ведь не орёл. А вот голосок подать петушки могут, гордо размахивая подрезаными крыльями.

Здравствуйте, rm2, Вы писали:

N>>А потом тот, кому твоя блокировка мешает, создаёт новую ветку (в SVN — каталог репы) как копию той, что ты заблокировал, пишет туда свои изменения, приходит к начальству "я тут супер пупер фичу забабахал, а меня не пускают", начальство даёт тебе по голове, снимает твою блокировку и мержит его версию.
Да даже всё проще. Тот просто может багу в релизной ветке править или типа того.

rm2>Нет. Они сидят и ждут
ЧТД: этот подход — контрпродуктивный. Типичный антипаттерн. Фтопку.

rm2>(но чаще всего работа распределяется таким образом, чтобы никто не пересекался по файлам).
Вот именно. И не только работа распределяется, но и структура проекта планируется таким образом, чтобы все друг-другу на пятки не наступали. А в этом случае блокировки, ВНЕЗАПНО, становятся не нужны.

rm2>А вот попытка создания ветки, да, приводит к ударам по головам.
Создание ветки приводит к ударам по головам только в плохих VCS, которые в ветки не умеют. Копия поддерева как в svn — это не ветка, а копия поддерева.

Единственный случай когда блокировки могут быть полезны, если работа идёт с большими бинарными файлами, которые мержить сложно. Это редкий случай для типичного git-репозитория и есть дополнительные инструменты типа git lfs, в котором внезапно есть локи.

Здравствуйте, ·, Вы писали:

·>ЧТД: этот подход — контрпродуктивный. Типичный антипаттерн. Фтопку.

Ни в коем случае. Антипаттерн — править один файл, а потом пытаться все это синхронизировать, бегая по отделам с вопросами "а это тебе на кой было делать". Т.е. получается, или вариант один работает, другой ждет (и на это время его можно на чтото другое переключить), или два работают над одним и тем же, а потом — и еще сверху работы по синхронизации. Куча лишней деятельности.

·>Вот именно. И не только работа распределяется, но и структура проекта планируется таким образом, чтобы все друг-другу на пятки не наступали. А в этом случае блокировки, ВНЕЗАПНО, становятся не нужны.

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

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Ну ясно же видно, что у него никаких перспектив:
ЭФ>https://stackshare.io/stackups/git-vs-mercurial

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

Здравствуйте, namespace, Вы писали:

N>Лично я гит терпеть не могу за весьма нетрадиционные подходы.
N>Инструмент хранения кода не должен мне говорить, как мне вести разработку.

Наоборот. Причины у этого чисто экономические.

Здравствуйте, sambl74, Вы писали:

S>"А судьи кто?" (c). Понятно, что сейчас все новички сразу садятся на git и смысла изучать что-то другое нет — так что и процент голосов вполне себе объясним. А так оно работало нормально ещё тогда, когда на git без слёз взглянуть было невозможно. Особенно под виндой.

Ну как — под cvs/svn/tfs бранчевание и слияние веток достигалось чудовищными тратами времени.

Здравствуйте, rm2, Вы писали:

rm2>Нужны нужны. Они явным образом дают понять, что в это лезть нельзя, и зазищают от случайных правок в стиле "были разведены, даже знали что туда лезть нельзя, но из памяти выпало/очень надо было/я чуть чуть".

Обычно в проектах слишком много мест, которые правятся всеми. И часто бывает так, что простой мерж гарантировано работать не будет.
Тогда надо выбирать — или все будут ждать, или же просто некто будет ответсвенным за работоспособность компонента. Второй вариант как то более эффективный — далеко не все измнения ломают, а только некоторые. А вынуждать ждать всех подряд идей крайне так себе.

Здравствуйте, Pauel, Вы писали:

P>Обычно в проектах слишком много мест, которые правятся всеми. И часто бывает так, что простой мерж гарантировано работать не будет.
P>Тогда надо выбирать — или все будут ждать, или же просто некто будет ответсвенным за работоспособность компонента. Второй вариант как то более эффективный — далеко не все измнения ломают, а только некоторые. А вынуждать ждать всех подряд идей крайне так себе.

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

А вот конкретных проблем изза того что обе стороны поправили один и тот же участок кода — такое бывало, да. В особенности если речь о интерфейсе — правки двух сторон в одну и ту же форму иногда просто невозможно синхронизировать.

Здравствуйте, rm2, Вы писали:

rm2>·>ЧТД: этот подход — контрпродуктивный. Типичный антипаттерн. Фтопку.
rm2>Ни в коем случае. Антипаттерн — править один файл, а потом пытаться все это синхронизировать,
Это неизбежная реальность. Подход гит лишь моделирует происходящие в реальности события. Блокировки и прочие недоветки — это попытка подогнать реальность под модель.

rm2>бегая по отделам с вопросами "а это тебе на кой было делать".
Шо за бред? Есть коммит-сообщения, их и читаем.

rm2>Т.е. получается, или вариант один работает, другой ждет (и на это время его можно на чтото другое переключить), или два работают над одним и тем же, а потом — и еще сверху работы по синхронизации. Куча лишней деятельности.
Это вменяемо может работать только на мелких проектах в три разработчика. Если разрабов становится больше, не дай боже в разных тайм-зонах... то начинается ад и ужас.

rm2>·>Вот именно. И не только работа распределяется, но и структура проекта планируется таким образом, чтобы все друг-другу на пятки не наступали. А в этом случае блокировки, ВНЕЗАПНО, становятся не нужны.
rm2>Нужны нужны. Они явным образом дают понять, что в это лезть нельзя, и зазищают от случайных правок в стиле "были разведены, даже знали что туда лезть нельзя, но из памяти выпало/очень надо было/я чуть чуть".
Что за код такой сакральный, в который лезть нельзя? Рабочая копия — это там где я работаю. И это моё дело что я правлю.

Здравствуйте, Pauel, Вы писали:

S>>"А судьи кто?" (c). Понятно, что сейчас все новички сразу садятся на git и смысла изучать что-то другое нет — так что и процент голосов вполне себе объясним. А так оно работало нормально ещё тогда, когда на git без слёз взглянуть было невозможно. Особенно под виндой.
P>Ну как — под cvs/svn/tfs бранчевание и слияние веток достигалось чудовищными тратами времени.

Но речь же тут не про cvs/svn/tfs а про mercurial, а он в плане слияний совершенно аналогичен гиту, и в целом это система того же уровня, с некоторыми отличиями в плане подходов (упор на неизменность истории, хотя аддоны и это правили), но принципиально — это так же точно распределенная система, с эффективной параллельной работой и слияниями.

Здравствуйте, rm2, Вы писали:

rm2>Эти слишком много обычно и не требуют длительных блокировок. В общем, незнаю, я лично не сталкивался с проблемами изза того что не могут чтото изменить т.к. заблокировано. Такое бывает — с коллегой, что заблокировал советуешься, и или временно разблокируют для тебЯ, или вместе
там правите, или переключаешься временно на чтото иное.

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

Здравствуйте, Pauel, Вы писали:

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

Ага, а синхронизация того что два чувака в одном месте наваяли прямо противоречащий друг другу код — не растягивает время, ага.

Здравствуйте, rm2, Вы писали:

P>>Сейчас команды становятся все более распределенными, потому вот это "советуешься" или растягивает время, или просто не работает. Потому стоит строить модель разработки без таких вот блокировок.
rm2>Ага, а синхронизация того что два чувака в одном месте наваяли прямо противоречащий друг другу код — не растягивает время, ага.
Неясно что у вас такое происходит в проекте, что у вас чуваки постоянно ваяют противоречащий код. В типичном проекте — это если происходит, то исчезающе редко, и вполне нормально в этом случае выдать конфликт, с чем гит хорошо справляется.
Если у вас это происходит часто, то это не норма, а болезнь, а использование локов — это "лечение" симптомов.
Ситуация, когда один и тот же файл правят разные люди одновременно — это объективная реальность. И цель vcs — управлять этим, а не запрещать.

Здравствуйте, fmiracle, Вы писали:

P>>Ну как — под cvs/svn/tfs бранчевание и слияние веток достигалось чудовищными тратами времени.
F>Но речь же тут не про cvs/svn/tfs а про mercurial, а он в плане слияний совершенно аналогичен гиту, и в целом это система того же уровня, с некоторыми отличиями в плане подходов (упор на неизменность истории, хотя аддоны и это правили),
Значительная разница заключается во внутреннем устройстве хранилища репозитория. В hg это старинный подход file revlog как в cvs/svn/tfs, а в git это принципиально иной object storage, content addressable system. Поэтому git позволяет более естественно описывать различные варианты и сценарии, аддоны/плагины это не хаки, не нашлёпки с боку, а просто разные алгоритмы над той же структурой данных.

F>но принципиально — это так же точно распределенная система, с эффективной параллельной работой и слияниями.
Нет. Он недораспределённая система. Имена бранчей, например, глобальны.

Здравствуйте, Aquilaware, Вы писали:

A>Использовать Git вместо Mercurial — это то же самое, что продолжать использовать CVS вместо SVN. Это родственные системы, делают одно и то же, одинаковым способом, но есть серьезные отличия в usability. Если попробовать их использовать на практике, то будет приблизительно такой расклад: у CVS операции все на ручнике, непродуманные, можно легко упороть репозиторий в плохое состояние, из которого потом трудно выйти; а у SVN все очень натуральное, хорошо визуализировано, понятные человеческие концепции, относительно простые и доступные операции. Да, делают они одно и то же, сходным способом. А теперь представьте себе мир извращенцев, которые до сих пор массово сидят на CVS. Это нормальные люди? Нет. Это либо неадекваты, либо заложники тулинга, либо несчастные рабы на потогонках, где приказано использовать соху и мотыгу в эпоху механизации.

A>Но откуда вам это это всё знать, если вы сразу вылупились в Git инкубаторе? Курица не улетит из своего уютного курятника, она ведь не орёл. А вот голосок подать петушки могут, гордо размахивая подрезаными крыльями.

Смешно написано

сохраню в виде цитаты, чтобы задать контекст.

Я работал с RCS, CVS, SVN, Arch (TLA), Mercurial, Git. Совсем немного с P4 и Darcs. И из этого всего выбираю Git. Причина очень проста: он единственный из всего этого набора, кто позволяет аккуратно и точно формировать в коммитах именно то, что должно быть для чёткой, ясной, понятной даже годы спустя, истории разработки. И делается у него это через index и interactive rebase.

Mercurial ближайший, кто приблизился к этому — факт. Но глупость его авторов, которые не поняли, насколько эта возможность является киллер-фичей, и попытка продвижения своих немасштабируемых маразматических концепций, как множественные головы вместе с желанием сделат "ещё один CVS/SVN, но распределённый", убили его в полёте. Кое-что и сейчас у него лучше, как хэндлинг бинарных диффов. Но это 0.1% потребностей.

Командная логика у Git, да, требует привыкания. Но при желании запомнить десяток простых правил — решается за два дня.

И к сравнению CVS и SVN: CVS убог, да, но прост и понятен. SVN ужасен тем, что не справились с управлением сложностью. Я с ним работал, сбежал на Git с радостью.

Вот вам мнение не "петушка из Git-инкубатора"

Здравствуйте, Pauel, Вы писали:

ЭФ>>Ну ясно же видно, что у него никаких перспектив:
ЭФ>>https://stackshare.io/stackups/git-vs-mercurial

P>А я вот смотрю, что целая куча команд работает с гитом как с меркуриалом — один upstream, только мерж, никаких ребейзов. 90% фич этого гита в такой модели просто невостребованы. Любая ошибка исправляется коммитом — или дофикшиваешь, или откатываешь.
P>Не знаю, насколько это массовое явление, но похоже гит дико переутяжелён.

На моём текущем проекте принудительная сериализация потока коммитов. Если CI может — ребейзит сам. Если нет — отдаёт автору на повтор.
Тут, наоборот, ребейзы вместо мержей. Ну не хотят люди ветвящуюся историю, принципиально. Может, их слишком CVS покусал.

А что заметная часть даже не думает делать amends и rebases... да, проблема.
Причём стандарные сервера типа GitHub, Gitlab, или BitBucket очень этому способствуют.
Как штатными средствами посмотреть разницу какого-то коммита версии 4 с версией 3, причём чтобы оно отделило разницу в самих правках коммитов от разницы в родительских коммитах?
Это умеет только Gerrit. Вот под ним тут возможна нормальная работа в стиле Git, а не распределённого SVN.

Здравствуйте, rm2, Вы писали:

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

rm2>Ага, а синхронизация того что два чувака в одном месте наваяли прямо противоречащий друг другу код — не растягивает время, ага.

А почему вы циклитесь тут на "в одном месте" и "один файл"?

Вот Вася переименовал void foo(long); в int bar(long); в include/buka.h. А Петя решил применить foo() в src/features/karuka.cpp, где foo() ещё ни разу не вызывалось. Как блокировка файла поможет им избежать конфликта по сути?

Конфликт в одном файле — это мелкий частный случай. Фича с его блокировкой нужна для песочниц. Для серьёзных проектов это тупо бесполезно.

Здравствуйте, rm2, Вы писали:

rm2>А вот конкретных проблем изза того что обе стороны поправили один и тот же участок кода — такое бывало, да. В особенности если речь о интерфейсе — правки двух сторон в одну и ту же форму иногда просто невозможно синхронизировать.

У вас там что, редактор форм все индексы сдвигает при этом?

Здравствуйте, rm2, Вы писали:

rm2>Здравствуйте, netch80, Вы писали:

N>>А потом тот, кому твоя блокировка мешает, создаёт новую ветку (в SVN — каталог репы) как копию той, что ты заблокировал, пишет туда свои изменения, приходит к начальству "я тут супер пупер фичу забабахал, а меня не пускают", начальство даёт тебе по голове, снимает твою блокировку и мержит его версию.

rm2>Нет. Они сидят и ждут (но чаще всего работа распределяется таким образом, чтобы никто не пересекался по файлам). А вот попытка создания ветки, да, приводит к ударам по головам.

О. То есть тимлиду теперь надо ещё и за файлами следить, где что реализовано.
А если файл это что-то вроде сводного интерфейса крупного пакета? Все стоят в очереди?

Здравствуйте, netch80, Вы писали:

N>У вас там что, редактор форм все индексы сдвигает при этом?

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

Здравствуйте, netch80, Вы писали:

N>А если файл это что-то вроде сводного интерфейса крупного пакета? Все стоят в очереди?

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

Здравствуйте, netch80, Вы писали:

N>Вот вам мнение не "петушка из Git-инкубатора"

Спасибо за ваш ответ, познавательно.

В мире Mercurial rebase это что-то сродни анафемы, его используют очень редко и в основном для того, чтобы ~~искупить грехи~~ выровнять какой-нибудь локальный косяк, пока позор не пошел в origin. Но чтобы делать его основой ежедневного ритуала, это считается почти злом.

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

The easy life и La dolce vita — это про Mercurial.

Здравствуйте, Aquilaware, Вы писали:

N>>Вот вам мнение не "петушка из Git-инкубатора"

A>Спасибо за ваш ответ, познавательно.
У меня опыта меньше, но я тоже прошел путь cvs -> svn -> (попытки с svk и hg) -> git.

A>В мире Mercurial rebase это что-то сродни анафемы, его используют очень редко и в основном для того, чтобы ~~искупить грехи~~ выровнять какой-нибудь локальный косяк, пока позор не пошел в origin. Но чтобы делать его основой ежедневного ритуала, это считается почти злом.
Зло — потому что в mercurial rebase сложно использовать, но это не закон природы. В git же rebase естественнен, хороший удобный инструмент.

A>Вместо этого в Mercurial на каждую большую фичу выделяется ветка, а когда фича более-менее готова и протестирована — она заливается в основную ветку одним скопом, поэтому годы спустя логическая история тех или иных изменений всё так же прекрасно просматривается и все интенции авторов естественным образом остаются на местах.
Такой же процесс ровно так же реализуется и в git. Но это не идеальный процесс. rebase даёт авторам явно выражать интенции, а не сливать навечно в публичные репы все душевные стенания автора, пока он работал над фичей. Вместо 30 коммитов с "fix typo", "forgot to change", будет 3 целостных коммита осмысленных изменений, каждый из которых легко ревьювить и смотреть годы спустя.

A>The easy life и La dolce vita — это про Mercurial.
И "шаг в сторону — расстрел".

Здравствуйте, ·, Вы писали:

·>Такой же процесс ровно так же реализуется и в git. Но это не идеальный процесс. rebase даёт авторам явно выражать интенции, а не сливать навечно в публичные репы все душевные стенания автора, пока он работал над фичей. Вместо 30 коммитов с "fix typo", "forgot to change", будет 3 целостных коммита осмысленных изменений, каждый из которых легко ревьювить и смотреть годы спустя.

Спасибо за инсайт. Эти "fix typо" не напрягают нисколечки, но видимо всегда будут люди, которые будут хотеть вмешиваться в ход истории для достижения своих целей (например, улучшения читабильности комитов в будущем).

Здравствуйте, Aquilaware, Вы писали:

A>·>Такой же процесс ровно так же реализуется и в git. Но это не идеальный процесс. rebase даёт авторам явно выражать интенции, а не сливать навечно в публичные репы все душевные стенания автора, пока он работал над фичей. Вместо 30 коммитов с "fix typo", "forgot to change", будет 3 целостных коммита осмысленных изменений, каждый из которых легко ревьювить и смотреть годы спустя.
A>Спасибо за инсайт. Эти "fix typо" не напрягают нисколечки,
Меня напрягает, когда читаешь какой-нибудь blame, хочется видеть внятное описание, соответствующие изменения в тестах, етс, а не там всякие бессмысленные fix typo. Приходится глубже зарываться в историю и ковырять месиво коммитов, ходить в github за пулл-реквестами и в джиру (если таки вписали правильный номер), отделять сигнал от шума.

A>но видимо всегда будут люди, которые будут хотеть вмешиваться в ход истории для достижения своих целей (например, улучшения читабильности комитов в будущем).
Ты те воспринимай это как "вмешиваться в историю [мыслей разработчика]", а как "организация изменений кода". Действительно ли так нужны мысли разраба? Код важнее.

Здравствуйте, Pauel, Вы писали:

P>Ну как — под cvs/svn/tfs бранчевание и слияние веток достигалось чудовищными тратами времени.

CVS особо не застал, но чёт не помню ничего такого фатального в SVN...

Здравствуйте, Aquilaware, Вы писали:

A>В мире Mercurial rebase это что-то сродни анафемы, его используют очень редко и в основном для того, чтобы ~~искупить грехи~~ выровнять какой-нибудь локальный косяк, пока позор не пошел в origin. Но чтобы делать его основой ежедневного ритуала, это считается почти злом.

Вот это и удивляет. Потом появляется цепочка коммитов типа:
"Исправлены аргументы в вызове функции foo."
"Ещё три вызова foo доработаны."
"Ещё два."
"Блин ещё один. Какого хера Петя такой глазастый, а я нет?"
"Самка собаки, продажная женщина, ещё два места забыл, лично тимлид нашёл и отругал. Надеюсь, теперь точно всё."

А свести это в один коммит перед фиксацией в публичной ветке — ни-ни, ересь, епитимья за это.

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

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

Только при этом вместо "логической истории" и "интенций авторов" ветка содержит воспоминания о том, что в понедельник все пришли с бодуна и не смогли вообще понять, что делать, поэтому коммиты 7-10 просто откатывают все правки коммитов 1-4 (причём вразброс), а 11-15 приводят весь тот мусор, что натворен в 5-6, в хоть какое-то рабочее состояние.

A>The easy life и La dolce vita — это про Mercurial.

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

Понятно, что публично (где-то "публичность" это "вышло за пределы отдела", например) опубликованная история это уже то, что менять сложно и часто неполезно. Но требование публикации хоть как-то законченного в неё устраняет уже 90-99% того, что не должно было вообще показываться.
Подход Git в этом смысле направлен на то, чтобы и через 50 лет можно было разбирать происходящее по сути, а не по тому, чей бодун был крепче.

Здравствуйте, rm2, Вы писали:

N>>У вас там что, редактор форм все индексы сдвигает при этом?

rm2>в mvs студии если серьезную форму править — то там просто сравнить то код со старым например вариантом очень сложно. Автогенератор может изменить порядок следования переменных/инициализирующих конструкций, во многих местах могут измениться размеры элементов и соотв. им инициализаторы — в общем, это довольно трудоемко такой код синхронизировать.

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

rm2> Если один товарищ вставил какую нибудь кнопку, откорректировав элементы всего интерфейса чтобы она влезла, а другой сделал тоже самое, но вставил другую кнопку — то все, это банально в каком нибудь арахисе уже не синхронизируешь.

И все размеры пересчитывать руками, потому что layout managers не даны или слабы?
С такими кривыми средствами вам действительно нужна сериализация изменений, согласен.
Делать её техническими средствами или административно — ну тут уже по вкусу.

ЭФ>Ну ясно же видно, что у него никаких перспектив:
ЭФ>https://stackshare.io/stackups/git-vs-mercurial

Может и нет, но git как то не спешит рещать проблемы с fetch/push больших реп на сервер, при почти неизбежном обрыве все надо начинать сначала.
Костыли в виде загрузки по тегам есть, но это именно костыли. Хотя казалось-бы, достаточно не выбрасывать на помойку уже загруженные на предидущей попытке обьекты — но вот фиг.
Вот народ и ищет хоть какую-то альтернативу.

Здравствуйте, netch80, Вы писали:

N>Понятно, что публично (где-то "публичность" это "вышло за пределы отдела", например) опубликованная история это уже то, что менять сложно и часто неполезно. Но требование публикации хоть как-то законченного в неё устраняет уже 90-99% того, что не должно было вообще показываться.

Это, кстати, да. Очень раздражают репозитории на GitHub'е, которые постоянно исторически плавают, постоянно эту историю скриптами передёргивают зачем-то. Как пример, тот же .NET — это не репозиторий, а какой-то неуловимый Джо.

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

Здравствуйте, Teolog, Вы писали:

ЭФ>>Ну ясно же видно, что у него никаких перспектив:
ЭФ>>https://stackshare.io/stackups/git-vs-mercurial
T>Может и нет, но git как то не спешит рещать проблемы с fetch/push больших реп на сервер, при почти неизбежном обрыве все надо начинать сначала.
T>Костыли в виде загрузки по тегам есть, но это именно костыли. Хотя казалось-бы, достаточно не выбрасывать на помойку уже загруженные на предидущей попытке обьекты — но вот фиг.
T>Вот народ и ищет хоть какую-то альтернативу.
Так в mercurial с этим ещё хуже. В git можно загрузить shallow clone и работать со свежим кодом, потом углубить, если надо. В mercurial можно лишь по номерам ревизий итерировать с начала, и пока всё не вытащишь, репа бесполезна.
В добавок, размер гит репы будет меньше.

Здравствуйте, netch80, Вы писали:

N>Ну вот я про это и говорю. Не знаю, что такое "mvs студия", но видел такое на многих старых инструментах. Постепенно это устраняли. Сейчас отсутствие такой самодеятельности считается необходимым признаком действительно профессионального инструмента.

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

Здравствуйте, ·, Вы писали:

A>>Спасибо за инсайт. Эти "fix typо" не напрягают нисколечки,
·>Меня напрягает, когда читаешь какой-нибудь blame, хочется видеть внятное описание, соответствующие изменения в тестах, етс, а не там всякие бессмысленные fix typo.

Сквошить надо при мерже в мастер или куда вы там мержите.

Здравствуйте, GarryIV, Вы писали:

A>>>Спасибо за инсайт. Эти "fix typо" не напрягают нисколечки,
GIV>·>Меня напрягает, когда читаешь какой-нибудь blame, хочется видеть внятное описание, соответствующие изменения в тестах, етс, а не там всякие бессмысленные fix typo.
GIV>Сквошить надо при мерже в мастер или куда вы там мержите.
squash это частный случай rebase. Для... ээ... частных случаев он, конечно, подходит. В общем случае имеет смысл иметь более одного коммита. Например, один коммит простой rename refactoring, меняющий 100500 файлов, а второй коммит — само изменение — 2 файла — код+тест. Сквошить такое не надо.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, netch80, Вы писали:

N>>Ну вот я про это и говорю. Не знаю, что такое "mvs студия", но видел такое на многих старых инструментах. Постепенно это устраняли. Сейчас отсутствие такой самодеятельности считается необходимым признаком действительно профессионального инструмента.

P>Устранили в основном за счет отказа от таких инструментов вообще или кастрировав их до посинения. В UI нет надежного способа сохранить, кто же первый, а кто второй. Визуально форма почти не меняется, а вот начинка может оказаться перепаханой на 100%.

Вот у меня например поля формы: фамилия, имя, год рождения. Понумерованы 1, 2, 3 соответственно, и где-то проставлены ссылки (например, порядок обхода 1 -> 2 -> 3). Теперь, надо добавить отчество и гражданство (перед годом рождения), они получили 4 и 5. Теперь порядок на экране и обхода 1 -> 4 -> 2 -> 5 -> 3. Всё, что завязано на поля 1, 2, 3 — не трогается. Зачем их трогать?
Вот это GUI редактор здорового человека, а не курильщика. И я в основном такие вижу в последнее время.

Здравствуйте, netch80, Вы писали:

N>Вот у меня например поля формы: фамилия, имя, год рождения. Понумерованы 1, 2, 3 соответственно, и где-то проставлены ссылки (например, порядок обхода 1 -> 2 -> 3). Теперь, надо добавить отчество и гражданство (перед годом рождения), они получили 4 и 5. Теперь порядок на экране и обхода 1 -> 4 -> 2 -> 5 -> 3. Всё, что завязано на поля 1, 2, 3 — не трогается. Зачем их трогать?

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

Еще пример. Вот один добавил кнопку. Второй добавил кнопку. Оба вливают свои изменения в мастер. У каждого нумерация одинаковая. Т.е. надо пофиксить привязки. А тут получается, что обе кнопки не влазят в форму. Надо мерж дополнить фиксом лайоута. То есть, разница в две кнопки, по одной у каждого, а мерж уже не дифабл.

Здравствуйте, netch80, Вы писали:

N>Но при желании запомнить десяток простых правил — решается за два дня.
Это каких правил?

... << RSDN@Home 1.3.110 alpha 5 rev. 62>>

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Что сейчас-то в 2022-м году минусы ставить? Прав я был кругом.

В чём ты прав? Что помимо своей тупой идеи "меркуриал не нужен", ещё и людей оскорбляешь? Смотри, как бы тебе интерфейс не начистили, умник! Прав он был...

B> В чём ты прав?

Если люди делают неправильный выбор, то кто они? Самые умные?

Здравствуйте, netch80, Вы писали:

N> И из этого всего выбираю Git. Причина очень проста: он единственный из всего этого набора, кто позволяет аккуратно и точно формировать в коммитах именно то, что должно быть для чёткой, ясной, понятной даже годы спустя, истории разработки.

Ты сейчас выпустил в воздух абсолютно бессмысленный набор каких-то абстрактных понятий и с умным видом выдаёшь это за "мнение". В нормальной терминологии это называют "пукнул в лужу".
Что именно в git коммите делается "чётко", что НЕ делается в Hg??

N> И делается у него это через index и interactive rebase.

эээ... да хоть через "слава КПСС", к чему эта узкотехническая лапша? Ты либо разжёвывай "вот гит — у него хорощо, потому что решает такие-то задачи", либо не надо сыпать этим git-only мусором.

N>Вот вам мнение не "петушка из Git-инкубатора"

Ну хоть тут чистая правда!

Не понимаю одного — вам Трольвадс глаза все зассал что ли??

Здравствуйте, Baiker, Вы писали:

B>Здравствуйте, netch80, Вы писали:

N>> И из этого всего выбираю Git. Причина очень проста: он единственный из всего этого набора, кто позволяет аккуратно и точно формировать в коммитах именно то, что должно быть для чёткой, ясной, понятной даже годы спустя, истории разработки.

B>Ты сейчас выпустил в воздух абсолютно бессмысленный набор каких-то абстрактных понятий и с умным видом выдаёшь это за "мнение". В нормальной терминологии это называют "пукнул в лужу".
B>Что именно в git коммите делается "чётко", что НЕ делается в Hg??

Завидую молодости и задору (10 лет, да?), хотя и не приемлю формы, в которых ты их выражаешь.

N>> И делается у него это через index и interactive rebase.
B>эээ... да хоть через "слава КПСС", к чему эта узкотехническая лапша? Ты либо разжёвывай "вот гит — у него хорощо, потому что решает такие-то задачи", либо не надо сыпать этим git-only мусором.

Всё было сказано, учись читать.

B>Не понимаю одного — вам Трольвадс глаза все зассал что ли??

Здравствуйте, ·, Вы писали:

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

·>Такой же процесс ровно так же реализуется и в git. Но это не идеальный процесс. rebase даёт авторам явно выражать интенции, а не сливать навечно в публичные репы все душевные стенания автора, пока он работал над фичей. Вместо 30 коммитов с "fix typo", "forgot to change", будет 3 целостных коммита осмысленных изменений, каждый из которых легко ревьювить и смотреть годы спустя.

Из этой бредятины единственная верная мысль, что "3 коммита легче смотреть, чем 30". НО(!) это сугубо право и профессионализм автора, сколько коммитов делать! Это твои личные абсурдные заявления, что коммитов будет 30.
Это ВООБЩЕ НИКАК не относится к инструменту. А вот что важно, так это то, насколько потом, год спустя, будет легко и наглядно найти, где автор "свернул не туда". Если программер решил, что делает что-то опасное, лучше сделать это отдельным коммитом, чтобы всегда можно было найти злополучный коммит и ответвиться шагом ранее. Т.е. обилие коммитов тут вообще не проблема. Коммит — это РЕШЕНИЕ АВТОРА, что некая веха завершена — можно заливать в репу. Не ты и ни Трольвадс будут решать, что с этим коммитом делать — только сам разработчик. Поэтому "схлопывание" коммитов — маразм с т.з. дальнейшего сопровождения ПО, ты тупо теряешь информацию!

Если пишешь всякие перделки командной строки, да ещё на языке, который сам месяц назад выучил, да ещё на гите, который ты так и не удосужился нормально выучить (потому что он написан через зад), то конечно же любые "хаки" в коммитах тебе понравятся! Благо, это не коммерческая разработка, а линупсятные страдания и за них "ничего не будет". Вот как только эти дрыщи из своих линупсов вылезут, как начнут разрабатывать сложные проекты, вот тогда вся "швабодка" им по мусалу и вылезет! Коммерция много чего перевоспитывает в маленьких "революционерах".

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Aquilaware, Вы писали:

A>>В мире Mercurial rebase это что-то сродни анафемы, его используют очень редко и в основном для того, чтобы ~~искупить грехи~~ выровнять какой-нибудь локальный косяк, пока позор не пошел в origin. Но чтобы делать его основой ежедневного ритуала, это считается почти злом.

N>Вот это и удивляет. Потом появляется цепочка коммитов типа:
N>"Исправлены аргументы в вызове функции foo."
N>"Ещё три вызова foo доработаны."
N>"Ещё два."
N>"Блин ещё один. Какого хера Петя такой глазастый, а я нет?"
N>"Самка собаки, продажная женщина, ещё два места забыл, лично тимлид нашёл и отругал. Надеюсь, теперь точно всё."

Замечательный симптом "сам пургу придумал, сам её опроверг, сам себя наградил печенькой"!

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

N>Понятно, что публично (где-то "публичность" это "вышло за пределы отдела", например) опубликованная история это уже то, что менять сложно и часто неполезно. Но требование публикации хоть как-то законченного в неё устраняет уже 90-99% того, что не должно было вообще показываться.

Это ты с одноклассниками решил, что "должно показываться"?

Вообще-то это дело программиста, ты тут каким боком??

Если есть коммит, значит ему место в истории. То, что школота делает коммит "отнечего делать" — проблема школоты, а не меркуриала. Главное — разумному прогеру даётся гибкий и адекватно спроектированный инструмент. И только студота на заре своей карьеры оптимистично думает "ща всё скомкаем вместе — получится один большой коммит!". Потому что они коммерческой разработки не видали. А вот когда покопаются в этом мусоре, так сразу и поумнеют и не будут трогать историю!

Здравствуйте, Baiker, Вы писали:

B>Из этой бредятины единственная верная мысль, что "3 коммита легче смотреть, чем 30". НО(!) это сугубо право и профессионализм автора, сколько коммитов делать! Это твои личные абсурдные заявления, что коммитов будет 30.
B>Это ВООБЩЕ НИКАК не относится к инструменту. А вот что важно, так это то, насколько потом, год спустя, будет легко и наглядно найти, где автор "свернул не туда". Если программер решил, что делает что-то опасное, лучше сделать это отдельным коммитом, чтобы всегда можно было найти злополучный коммит и ответвиться шагом ранее. Т.е. обилие коммитов тут вообще не проблема. Коммит — это РЕШЕНИЕ АВТОРА, что некая веха завершена — можно заливать в репу.

Вот именно, что для того, чтобы показать такое решение, часто требуется несколько итераций с корректировкой предшествующих фиксаций. Поэтому средство, позволяющее простыми штатными средствами окончить такое "РЕШЕНИЕ АВТОРА" (то есть Git), будет лучше средства, где это можно делать только окольными усложнёнными путями (то есть Hg).

B> Не ты и ни Трольвадс будут решать, что с этим коммитом делать — только сам разработчик. Поэтому "схлопывание" коммитов — маразм с т.з. дальнейшего сопровождения ПО, ты тупо теряешь информацию!

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

B>Если пишешь всякие перделки командной строки, да ещё на языке, который сам месяц назад выучил, да ещё на гите, который ты так и не удосужился нормально выучить (потому что он написан через зад), то конечно же любые "хаки" в коммитах тебе понравятся! Благо, это не коммерческая разработка, а линупсятные страдания и за них "ничего не будет". Вот как только эти дрыщи из своих линупсов вылезут, как начнут разрабатывать сложные проекты, вот тогда вся "швабодка" им по мусалу и вылезет! Коммерция много чего перевоспитывает в маленьких "революционерах".

Скоро у тебя так вся лужа выкипит.

Здравствуйте, Baiker, Вы писали:

B>Замечательный симптом "сам пургу придумал, сам её опроверг, сам себя наградил печенькой"!

Просто практика.

B>На деле, программист как профессионал сам знает, что и когда коммитить. И не вам, сторонним "икспердам", решать, глупый это коммит или нет.

Именно нам, если мы коллеги.

B> Есть изменение — есть коммит, в этом абсолютно никакого криминала нет. Надо будет — любую изменённую строчку можно найти, не имеет значения, в каком именно коммите.

Имеет. Например, для bisection резко полезнее, когда каждый коммит компилируется и тестируется.

B> Главное — есть историческая цепочка изменений, её легко можно проследить по каждому шагу. А если какой-то молодой подаван сдуру всё "схлопнул" ребэйзом, то лопата вам в помощь разгребать это говно, где будут СОТНИ изменений одним флаконом.

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

B>Это ты с одноклассниками решил, что "должно показываться"?

Вообще-то это дело программиста, ты тут каким боком??

Я коллега по работе, значит, моё дело. Мне потом с этим работать.

B> Если есть коммит, значит ему место в истории.

Нет.

B> То, что школота делает коммит "отнечего делать" — проблема школоты, а не меркуриала.

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

B> Главное — разумному прогеру даётся гибкий и адекватно спроектированный инструмент.

Именно. И сейчас этим требованиям удовлетворяет только Git. И то — не со всеми серверами.

B> И только студота на заре своей карьеры оптимистично думает "ща всё скомкаем вместе — получится один большой коммит!". Потому что они коммерческой разработки не видали. А вот когда покопаются в этом мусоре, так сразу и поумнеют и не будут трогать историю!

Перестань бороться на публику с собственными галлюцинациями. Всё равно кроме тебя они никому не видны.

Здравствуйте, ·, Вы писали:

GIV>>Сквошить надо при мерже в мастер или куда вы там мержите.
·>squash это частный случай rebase. Для... ээ... частных случаев он, конечно, подходит. В общем случае имеет смысл иметь более одного коммита.

Каждый коммит в основную (или долгоиграющую) ветку должен быть осмысленным. Желательно 1 к 1 соотносится с задачей в жыре, без git merge --squash мм удачи потом историю смотреть. Понятно, что можно осознано выбирать вид мержа и это в теории может быть хорошо но по факту на если не форсить то будут мержить как попало и что попало, увы.

Здравствуйте, Baiker, Вы писали:

B>·>Такой же процесс ровно так же реализуется и в git. Но это не идеальный процесс. rebase даёт авторам явно выражать интенции, а не сливать навечно в публичные репы все душевные стенания автора, пока он работал над фичей. Вместо 30 коммитов с "fix typo", "forgot to change", будет 3 целостных коммита осмысленных изменений, каждый из которых легко ревьювить и смотреть годы спустя.
B>Из этой бредятины единственная верная мысль, что "3 коммита легче смотреть, чем 30". НО(!) это сугубо право и профессионализм автора, сколько коммитов делать! Это твои личные абсурдные заявления, что коммитов будет 30.
B>Это ВООБЩЕ НИКАК не относится к инструменту. А вот что важно, так это то, насколько потом, год спустя, будет легко и наглядно найти, где автор "свернул не туда". Если программер решил, что делает что-то опасное, лучше сделать это отдельным коммитом, чтобы всегда можно было найти злополучный коммит и ответвиться шагом ранее. Т.е. обилие коммитов тут вообще не проблема. Коммит — это РЕШЕНИЕ АВТОРА, что некая веха завершена — можно заливать в репу.
Решение может быть неверное, т.к. можно забыть что-то добавить. Rebase это инструмент исправления ошибок.

B>Не ты и ни Трольвадс будут решать, что с этим коммитом делать — только сам разработчик.
Торвальдс лишь дал инструмент, чтобы разработчик мог легко манипулировать коммитами.

B>Поэтому "схлопывание" коммитов — маразм
Бездумное схлопывание коммитов предложили тут. И да, я тоже с этим не согласен.

B>с т.з. дальнейшего сопровождения ПО, ты тупо теряешь информацию!
rebase позволяет и разделять коммиты. И даже просто менять их порядок. Т.е. rebase обычно используют чтобы _добавить_ информацию, которую забыли добавить в момент коммита.

B>так и не удосужился нормально выучить
git прост до безобразия, git — the stupid content tracker, скоро освоишь, какие твои годы.

Здравствуйте, GarryIV, Вы писали:

GIV>>>Сквошить надо при мерже в мастер или куда вы там мержите.
GIV>·>squash это частный случай rebase. Для... ээ... частных случаев он, конечно, подходит. В общем случае имеет смысл иметь более одного коммита.
GIV>Каждый коммит в основную (или долгоиграющую) ветку должен быть осмысленным. Желательно 1 к 1 соотносится с задачей в жыре, без git merge --squash мм удачи потом историю смотреть. Понятно, что можно осознано выбирать вид мержа и это в теории может быть хорошо но по факту на если не форсить то будут мержить как попало и что попало, увы.
Бездумное схлопывание коммитов не повышает качество истории. А если вся джира и так укладывается в один коммит, то проще commit --amend делать (на крайняк по reflog-у откатываться), тогда и --squash не нужен.

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, ·, Вы писали:

GIV>>>Сквошить надо при мерже в мастер или куда вы там мержите.
GIV>·>squash это частный случай rebase. Для... ээ... частных случаев он, конечно, подходит. В общем случае имеет смысл иметь более одного коммита.

GIV>Каждый коммит в основную (или долгоиграющую) ветку должен быть осмысленным.

Да.

GIV> Желательно 1 к 1 соотносится с задачей в жыре,

С чего бы это вдруг?

GIV> без git merge --squash мм удачи потом историю смотреть.

В чём вы видите проблему?

GIV> Понятно, что можно осознано выбирать вид мержа и это в теории может быть хорошо но по факту на если не форсить то будут мержить как попало и что попало, увы.

С чего бы это вдруг? Что, так сложно это контролировать?

Здравствуйте, netch80, Вы писали:

GIV>> Желательно 1 к 1 соотносится с задачей в жыре,
N>С чего бы это вдруг?
Удобно

GIV>> без git merge --squash мм удачи потом историю смотреть.
N>В чём вы видите проблему?
Рекомендую перечитать ветку

GIV>> Понятно, что можно осознано выбирать вид мержа и это в теории может быть хорошо но по факту на если не форсить то будут мержить как попало и что попало, увы.
N>С чего бы это вдруг? Что, так сложно это контролировать?
Я бы сказал невозможно.

Здравствуйте, sambl74, Вы писали:

S>CVS особо не застал, но чёт не помню ничего такого фатального в SVN...

Работает медленно, невозможно создать свою локальную ветку, работать большой командой намного сложнее

Здравствуйте, GarryIV, Вы писали:

GIV>>> Желательно 1 к 1 соотносится с задачей в жыре,
N>>С чего бы это вдруг?
GIV>Удобно

Без глубокого обоснуя — неубедительно. Я работал в варианте и с 60 коммитами на тикет. Никаких проблем в этом нет, а вот от попытки собрать всё в один коммит — есть.

GIV>>> без git merge --squash мм удачи потом историю смотреть.
N>>В чём вы видите проблему?
GIV>Рекомендую перечитать ветку

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

GIV>>> Понятно, что можно осознано выбирать вид мержа и это в теории может быть хорошо но по факту на если не форсить то будут мержить как попало и что попало, увы.
N>>С чего бы это вдруг? Что, так сложно это контролировать?
GIV>Я бы сказал невозможно.

В ваших краях не слышали, что есть инструменты, которые позволяют этим управлять? Даже про peer review с проставлением оценок не слышали? Ну, у вас всё впереди, но отставать на 15-20 лет от отрасли это точно проблема...

Здравствуйте, Baiker, Вы писали:

B>Если пишешь всякие перделки командной строки, да ещё на языке, который сам месяц назад выучил, да ещё на гите, который ты так и не удосужился нормально выучить (потому что он написан через зад), то конечно же любые "хаки" в коммитах тебе понравятся! Благо, это не коммерческая разработка, а линупсятные страдания и за них "ничего не будет". Вот как только эти дрыщи из своих линупсов вылезут, как начнут разрабатывать сложные проекты, вот тогда вся "швабодка" им по мусалу и вылезет! Коммерция много чего перевоспитывает в маленьких "революционерах".

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

Здравствуйте, Baiker, Вы писали:

B>Не понимаю одного — вам Трольвадс глаза все зассал что ли??

Подумаешь, какой-то пузатый дурачок-троечник "нечаянный линупс" запилил (убожество, за коотрое стыдно даже спустя годы). Теперь что, каждый "вздох ПэЖэ" будете обдрачивать? Начните уже как-то иметь СВОЁ мнение, а то как-то даже смешно наблюдать эту линупсовую массовую болезнь гитом.

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

Плохо Линуксу будет когда Торвальдс уйдет, так как вся идеолония и прогресс этой ОС до сих пор вертятся вокруг него.

Поэтому всё происходящее сейчас обуславливается не столько "засанными глазами", сколько эффектом инерции. Чтобы была инерция, должны быть движение и масса, и это всё в наличии.

Здравствуйте, netch80, Вы писали:

N>Никакой проблемы ни в дофига коммитов на тикет, ни в дофига коммитов на субветку — нет.
Тогда определенно тебе сквош не нужен. Совет был для тех у кого такоые проблемы есть. У меня например есть.
Удачи тебе и хорошего настроения

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, netch80, Вы писали:

N>>Никакой проблемы ни в дофига коммитов на тикет, ни в дофига коммитов на субветку — нет.
GIV>Тогда определенно тебе сквош не нужен. Совет был для тех у кого такоые проблемы есть. У меня например есть.

Тогда объясни, пожалуйста, в чём конкретно они заключаются и, если можно, откуда берутся.
Мне искренне непонятно.

GIV>Удачи тебе и хорошего настроения

взаимно

но вопрос сверху по-прежнему в силе.

Здравствуйте, Nuzhny, Вы писали:

S>>CVS особо не застал, но чёт не помню ничего такого фатального в SVN...

N>Работает медленно, невозможно создать свою локальную ветку, работать большой командой намного сложнее

Мне как-то случилось поработать аж две недели в одной конторе, в которой в 2015 году был CVS (!)

Ну, вопрос решился достаточно легко с помощью локального Git. Я импортировал изменения из CVS в отдельную ветку и мержил её, а свои разработки, оформив, отправлял CVSʼом.

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

От:	Эйнсток Файр	Странный реагент
Дата:	14.04.18 15:17
Оценка:	+1 -2

	От:	vsb
	Дата:	14.04.18 15:29
	Оценка:	+2

От:	Эйнсток Файр	Странный реагент
Дата:	14.04.18 15:35
Оценка:

	От:	vsb
	Дата:	14.04.18 15:48
	Оценка:

	От:	Somescout
	Дата:	14.04.18 16:17
	Оценка:	+1

От:	Pzz	https://github.com/alexpevzner
Дата:	14.04.18 17:05
Оценка:

	От:	Sharowarsheg
	Дата:	14.04.18 17:52
	Оценка:	1 (1)

От:	denisko	http://sdeniskos.blogspot.com/
Дата:	14.04.18 18:05
Оценка:

От:	_NN_	www.nemerleweb.com
Дата:	15.04.18 05:56
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	21.04.18 12:45
Оценка:

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	16.05.18 00:21
Оценка:	+1

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	04.09.22 14:24
Оценка:

	От:	Aquilaware
	Дата:	05.09.22 10:59
	Оценка:	+2 -1

От:	Pauel	http://blogs.rsdn.org/ikemefula
Дата:	05.09.22 11:32
Оценка:

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	08.09.22 07:30
Оценка:

От:	Vladek	Github
Дата:	16.04.18 09:13
Оценка:

	От:	alexzzzz
	Дата:	16.04.18 14:33
	Оценка:

От:	Vladek	Github
Дата:	16.04.18 18:02
Оценка:

	От:	sambl74
	Дата:	16.04.18 18:13
	Оценка: