Там опять Go ругают

А сишечка - она?

Сишечка мертва.

Смешная шутка...
Никто ничего системного не пишет ни на чем, кроме С.
Есть пет-проекты, есть PoC'и, живого нет.
Это медицинский факт.

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

Про Rust нет уверенности, что он переживёт десятилетие, ибо это проходной язык.

Никто ничего системного не пишет ни на чем, кроме С.

Осталось понять, что подразумевать под системщиной.

Сишечка мертва.

Во влажных мечтах RUSTешишечек.

Никто ничего системного не пишет ни на чем, кроме С.

Ну хоть не споришь с этим фактом, уже хорошо.

Сишечка мертва.

Вы плотно работаете с «мёртвыми» языками, потому что за «живые» не платят?

Вы плотно работаете с «мёртвыми» языками, потому что за «живые» не платят?

Последние два ваших поста (этот и C рулит и педалит. (комментарий) ) – вообще шик, обожаю, когда Разорванного Флакона публично тыкают носом в его же дерьмо.

https://github.com/RazrFalcon/rustybuzz

Кто-то же должен разгребать этот треш.

...говорят все те, кто ни разу не открывал сишные сорцы.

А те, кто открывал, добавляют, что ещё и попахивает? Или в чём идея?

Навоз тоже попахивает, но огород им удобряют, несмотря на.
Юниксовые ядра написаны на C, драйвера написаны на C, системная обвязка в виде клиентов, демонов и прочих systemd написана на С, nginx написан на С, redis написан на C, openssl написан на C, curl, который тут светили, тоже написан на C. Слишком много активных и известных проектов для умирающего языка, не находишь? А ведь это все даже не плюсы, pure C.

Ну вот, смотри: helloworld_v.1.0.rs написан на Rust, helloworld_v1.1.rs написан на Rust, плюс helloworld_v1.2.rs написан на Rust, helloworld_v.2.0.rs написан на Rust, helloworld_v3.0.rs написан на Rust, helloworld_v22.0.3.rs, который тут светили, тоже написан на Rust.

Шах и мат, атеисты.

Разорванный Флакон

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

Что это доказывает? Если я открою исходники с коболом, я увижу кобол. И его тоже ещё очень много.

Это доказывает, что есть много легаси, которое приходится поддерживать и развивать.

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

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

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

Так в «кончине С» и заключался основной тезис. О чем мы тогда тут спорим?
Я, например, тоже могу справедливо заявить, что популярность JS основана на отсутствии альтернатив, но меняет ли это современные тренды? Нет. Какими бы ни были причины, факт остается фактом.

Так в «кончине С» и заключался основной тезис. О чем мы тогда тут спорим?

О том, что «много строк кода» не гарантия живости языка. И о том, что живость языка не означает отсутствие в нём проблем.

О, я думал, что мы об этом:

Сишечка мертва.

Ветку разговора иногда стоит проматывать до начала.

О том, что «много строк кода» не гарантия живости языка

Не гарантия, но речь не просто о «строках кода», а об активно поддерживаемых и развиваемых «строках кода». Вот с COBOL, КМК, большинство уже переехало на Java, поэтому можно сказать, что он мертв или бьется в предсмертной агонии.

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

Ай-яй-яй! Не нужно мне приписывать того, чего я никогда не говорил, проблем в C более чем достаточно.

Вот с COBOL, КМК, большинство уже переехало на Java, поэтому можно сказать, что он мертв или бьется в предсмертной агонии.

Если вам кажется, что COBOL мертв, то неудивительно, что вам кажется, что чистый Си жив.

https://www.i-programmer.info/news/99-professional/13484-survey-says-cobol-still-going-strong.html

Если COBOL жив, то сишечка вообще галопом по улицам бегает.

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

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

вот я, со 100% могу сказать, что c/c++ - это ходячий труп, потому что есть более хорошие инструменты. если делать софт, от которого зависят жизни, то лучше я выберу Go.

теперь что касается rust

rust, это ошибочная технология, не имеющая под собой достаточного смыслового основания: Mozilla просто не хотела кодить на C++, и не хотела смотреть на Go (она же гордая), и не знала про существование D.

в подтверждение не очень умной политике Mozilla, можно привести пример со слитой технологией XUL - это вообще эпик :|

Про Си объяснил, что касается COBOL - это больше опыт общения с человеком, который на нем долго писал.
Если сравнивать, то по C вакансий банально больше, так что более мертвым он быть точно не может.

вот я, со 100% могу сказать, что c/c++ - это ходячий труп, потому что есть более хорошие инструменты. если делать софт, от которого зависят жизни, то лучше я выберу Go.

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

Кстати, да: https://habr.com/ru/post/487116/ .

нужно ооочень сильно постараться, чтобы сборка мусора Go стала сколько либо заметна.

да видел я эту статью:

1. вероятно они неправильно заархитектили
2. вероятно они специально и упорно неправильно заархитектили

короче, этот опыт - не показателен.

Про Си объяснил

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

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

как говорится Show Me the Code. - это не про Дискач

Разумеется, но это, опять же, известные, широко используемые и развиваемые копролиты, для парочки из которых нет альтернатив. Так в чем заключается претензия?

Так в чем заключается претензия?

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

Тогда как, на мой взгляд, ситуация с чистым С достаточно непростая:

• чистый C не умрет, т.к. ничего лучшего для организации FFI пока не придумано. И вряд ли будет придумано в ближайшие десятилетия;

• чистый С никуда в ближайшие годы просто так не уйдет из завязанной на Unix-ы системщины (в частности Linux-овщины);

• чистый С никуда не уйдет из-за большого количества недопрограммистов, не могущих ни во что сложнее чистого С. Кто-то из-за своей тупости (таких немало, к сожалению), кто-то из-за того, что разработка на C для них – это вообще побочный вид деятельности;

• чистый С убог настолько, что разрабатывать на нем что-то вне Unix-овой системщины могут либо мазохисты, либо не имеющие достаточной квалификации люди.

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

Ну и надеюсь, что даже в тех узких нишах, где адепты чистой С-шки все еще с удовольствием его применяют, со временем присутствие более адекватных альтернатив (будь то C++, Rust или Ada) будет только усиливаться.

чистый C не умрет, т.к. ничего лучшего для организации FFI пока не придумано.

Лучше-то придумано. Но С используется только по причине легаси. При этом как клей для разных языков он убог чуть менее чем полностью. Начиная от отсутствия слайсов и заканчивая переусложнённым синтаксисом. Радует что хоть stdbool.h и stdint.h завезли.

Самая перспективная альтернатива - это web idl.

А когда внезапно станет заметена у проекта наступят очень интересные времена с ручными пулами объектов.

Все по существу, но есть нюансы.

Во-первых, если я правильно понимаю, то кодовая база COBOL - это в первую очередь системы, созданные десятки лет назад, и существующие только в рамках компаний, где они были разработаны. Я попробовал найти в открытом доступе проект, сравнимый по масштабам с, не знаю, OpenSSL, Node.js, etc, но не смог. Если такие есть, то было бы любопытно взглянуть. Почему это важно? Потому что это формирует комьюнити вокруг языка, которое потом держит такой язык на плаву.

Во-вторых, юниксовая экосистема - это, безусловно, легаси, но это то легаси, которое готовы активно использовать прямо сейчас для новых проектов: будь то сервера в датацентрах, будь то прошивка для какого-то девайса, будь то DPI под закон Яровой в соответствии с требованиями Роскомнадзора. Все это в конечном счете продлевает жизнь как юниксов, так и сишки, на которой они в том числе написаны. А кто сейчас готов использовать COBOL помимо тех, кто уже 30 лет его использует?

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

Я в общем-то не спорю, что C - сугубо нишевой язык, но он будет жив как минимум столько, сколько Unix-системы с их обвязкой будут существовать в том виде, в котором существуют сейчас. С другой стороны, COBOL, на мой взгляд, больше не дает заколотить крышку гроба, чем живет.

С используется только по причине легаси

вообще-то С - майнстрим, область использования сужается с появлением всяких DSL.

Причем с учетом того что в Go совершенно уродский GC, пропустивший, как и все остальное в Go, последние 50 лет развития технологий…

Даже если сишечка мертва, то как зомби она будет существовать ещё сотни лет

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

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

Юниксовые ядра написаны на C, драйвера написаны на C, системная обвязка в виде клиентов, демонов и прочих systemd написана на С, nginx написан на С, redis написан на C, openssl написан на C, curl, который тут светили, тоже написан на C. Слишком много активных и известных проектов для умирающего языка, не находишь?

Умирающесть определяется тенденцией, а не точечным состоянием. А тенденция такая - Си умирает.

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

написанную на Си команду гита

так git реализации не только на C есть.. погуглить за тебя?)

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

Повторишь это, когда наберешь написанную на Си команду гита, чтобы запушить новые строчки на Расте

Гит - редкостный кусок дерьма, слепленный на коленке по мотивам проприетарного софта. Лично я предпочитаю Hg.

Если и кусок дерьма, то ужасно популярный. Ну да ладно.

Если и кусок дерьма, то ужасно популярный. Ну да ладно.

http://lurkmore.to/Миллионы_не_могут_ошибаться

разве что они англичане :D

Ну началось.
- В Гугле юзают Го и Пайтон? В Гугле сидят одни идиоты! Я умнее. Тысячи, десятки тысяч проектов используют git? Ими занимается тупое, сраное быдло! Я не такой.
Заметь, я даже не говорил о том, хорош git или плох, я изначально намекал на популярность, а популярность для ПО - это в общем-то жизнь.

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

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

А ты пропустил наш разговор про Си несколько недель назад. Мы обсуждали историю создания Си, паскаля, как один победил другой, какие в то время были альтернативы. Суть в том, что мир компьютеров был совсем другой, абсолютно не похожий на современность, и Си был выбран потому, что остальное было еще хуже. Ты представляешь, насколько тогда всё было печально, если остальное было хуже, чем Си? Ты представляешь, что Хоару и Вирту пришлось долго рвать очко просто для того, чтобы добиться принятия рекурсии в стандарт Алгол 60? Тогда была диктатура кабинетных бездарностей, высиравших одно за одним никуда не годившиеся решения, и потому любая мало-мальски годная софтина сразу расхватывалась, как горячие пирожки. Это было время васика без вызова функций, где вместо них применялись переходы к номеру строки, время фортрана без рекурсий, без циклов, и с ветвлением без else, время MUMPS, программы на котором до боли напоминают brainfuck, и еще куча полнейшего угара.

Однако, ситуация изменилась уже в 80-х. Куча наследия доказывает совсем другое - это technical debt планетарного масштаба, провал имевшейся тогда модели организации экономики, у которой, однако, были поставлены сверху иные приоритеты (как минимум в то время).

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

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

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

Welcome to the real world.

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

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

если бы они плохо работали - никто бы их не дергал а писали бы более лучшее на других языках и где это нужно - давно переписано.

Если вам кажется, что COBOL мертв, то неудивительно, что вам кажется, что чистый Си жив.
https://www.i-programmer.info/news/99-professional/13484-survey-says-cobol-st...

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

Причем с учетом того что в Go совершенно уродский GC, пропустивший, как и все остальное в Go, последние 50 лет развития технологий…

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

Что значит «с довольно скромными паузами»? Для кого скромные, а для кого невыносимые.

Дело в том что там тупой примитивнейший mark-n-sweep.

Инкрементальный? Вот это бы пригодилось и для параллельных вычислений, и для HPC. Но нет, там тупой Stop The World.

Ну хотя бы Compacting? Нет, не Compacting, привет фрагментация и промахи кеша.

Generational? Нет, еще один привет вышеупомянутому stop the world.

Там обычный Mark-N-Sweep уровня 70х, как и всё в Go.

В Гугле юзают Го и Пайтон? В Гугле сидят одни идиоты! Я умнее. Тысячи, десятки тысяч проектов используют git? Ими занимается тупое, сраное быдло! Я не такой.
Заметь, я даже не говорил о том, хорош git или плох, я изначально намекал на популярность, а популярность для ПО - это в общем-то жизнь

Не надо приписывать мне слова, которые я не писал. Я как раз примерно в курсе, как принимались решения в гугле, как лисперов садили писать код на Java, как делалось Go и почему оно не делалось раньше, как делалось Darts и провалилось, и так далее. А для управления версиями гугл в основном использует Perforce, а не кривущий Git.

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

Разрешите не согласиться. Контрпримеры: PHP, MySQL. Я бы все-таки акцентировал внимание на раскрутке и маркетинге, как на центральных, а желание левой пятки менеджера может быть опционально.

Шутка юмора.
А какие проблемы у гита? Я для себя вынес пока только одну действительно раздражающую - проблемы с историей коммитов для папки или файла после git mv.

если бы они плохо работали - никто бы их не дергал а писали бы более лучшее на других языках и где это нужно - давно переписано

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

но этого процесс много где затянулся.

вот уж действительно, слава БГ, что на rust не переписывают.. и если думать в этом наклонении, то мозилле и правда скоро кердык.. года через 3.

Ну хотя бы Compacting? Нет, не Compacting, привет фрагментация и промахи кеша

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

Generational? Нет, еще один привет вышеупомянутому stop the world

Go, в отличие от каких-нибудь Java и Python, не размещает локальные/временные переменные в куче, потому не имеет проблемы большого числа молодых объектов. При этом, у параллельного сборщика длительность stop-the-world не зависит от размера кучи/поколения.

А какие проблемы у гита? Я для себя вынес пока только одну действительно раздражающую - проблемы с историей коммитов для папки или файла после git mv

Именно благодаря заложенному функционалу изменения истории у Git есть такая замечательная фича, как возможность убить репозиторий до невосстанавливаемого состояния. Конечно, на stackoverflow можно найти рецепты даже для самых запущенных случаев — правда, не факт, что лично я или другой простой разработчик сможет подобный репозиторий восстановить.

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

hg update [-C|-c|-m] [-d DATE] [[-r] REV]

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​]

Именно благодаря заложенному функционалу изменения истории у Git есть такая замечательная фича, как возможность убить репозиторий до невосстанавливаемого состояния.

«Если вы спроектируете систему из расчёта на идиотов, то только идиоты и будут ей пользоваться»

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

NOTABUG OUTOFSCOPE

Git просто вываливает тебе на голову все свои кишки, потому что разрабы (не будем лишний раз указывать имена) не смогли и не захотели придумать, как сделать операции скрытыми и автоматическими.

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Ну я немного про другое. Например, когда я хочу глянуть историю коммитов для конкретной директории bla-bla-bla, то делаю git log bla-bla-bla. Все хорошо. Однако если ее переименую в bla-bla, то git log покажет только один коммит «Rename bla-bla-bla to bla-bla». Для отдельного файла в папке я еще могу увидеть всю историю, но для папки целиком - no way, надо переносить особым образом, переписывая, да, дерево коммитов. Проблема в том, что гит отслеживает только изменения файлов, а на директории ему насрать - отсюда этот бессмысленный пердолинг.

Именно благодаря заложенному функционалу изменения истории у Git есть такая замечательная фича, как возможность убить репозиторий до невосстанавливаемого состояния.

Маловероятно, у каждого разработчика есть локальная копия репозитория + обязательно должны быть регулярные бэкапы + система вроде gitea или gitlab с разделением прав доступа для репозиториев и веток, где можно как запретить force push, требуемый для перезаписи истории, так и вообще ограничить список тех, кто может делать коммиты напрямую в ветку, минуя merge requests.

Перезапись истории - это фишка а-ля unsafe в Rust. Как бы можно, но как бы не надо. Лично меня в свое время она сильно выручила, когда я колдовал, реорганизовывая submodules в проекте.

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

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

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Нет, это исчерпывающий список опций «hg update». Остальные опции Git - это опасные ручные команды и просто плохо продуманные особенности работы. Например, режима «detached head» в Mercurial нет, однако, он не потерял от этого функционала по сравнению с Git:
https://www.mercurial-scm.org/wiki/GitConcepts#Branch_model

Последний вариант вызова, «git checkout (-p|--patch)», пришел на замену двум длинным предыдущим командам, и эквивалентен «hg update (-m|--merge)» — этот механизм намного проще и удобнее для человека, который не писал и не читал исходные коды Git.

Однако если ее переименую в bla-bla, то git log покажет только один коммит «Rename bla-bla-bla to bla-bla». Для отдельного файла в папке я еще могу увидеть всю историю, но для папки целиком - no way, надо переносить особым образом, переписывая, да, дерево коммитов. Проблема в том, что гит отслеживает только изменения файлов, а на директории ему насрать - отсюда этот бессмысленный пердолинг

В Mercurial проблема решается через «hg log --follow», например.

Маловероятно, у каждого разработчика есть локальная копия репозитория + обязательно должны быть регулярные бэкапы

Ну ясен пень, что SCM распределенная, а значит у всех полная копия — однако, свои правки ты потеряешь.

Перезапись истории - это фишка а-ля unsafe в Rust. Как бы можно, но как бы не надо. Лично меня в свое время она сильно выручила, когда я колдовал, реорганизовывая submodules в проекте.

Ты фактически создаешь новый репозиторий с потерей истории. Если же происходит простое перемещение/переименование - я уже упомянул «hg log --follow».

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

А у вас за rebase руки еще не отрывают?

В Mercurial проблема решается через «hg log --follow», например.

Тут так же, но не для директорий. Это архитектурный просчет гита.

Ну ясен пень, что SCM распределенная, а значит у всех полная копия — однако, свои правки ты потеряешь.

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

Ты фактически создаешь новый репозиторий с потерей истории. Если же происходит простое перемещение/переименование - я уже упомянул «hg log --follow».

Да, поэтому в общем случае так делать не надо, и эту функцию блокируют. Она для тех, кто понимает, что делает, и предварительно подготовил бэкап.

А у вас за rebase руки еще не отрывают?

А почему должны? Как по мне, только так и нужно. Все слияния в транк только сквошем и фастфорвардом, потом там аккуратная история, на которую приятно смотреть.

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Нет, это исчерпывающий список опций «hg update»

Понятно, первый вариант.

Остальные опции Git - это опасные ручные команды и просто плохо продуманные особенности работы.

«Вражеские гнусные шпионы и наши доблестные разведчики», ага.

Ну, про опасность и идиотов я уже написал, а в чём заключается плохо продуманность?

Например, режима «detached head» в Mercurial нет

…зато есть механизм безымянных веток, только у них тоже могут быть имена, но это другие имена :D

И эти люди запрещают нам ковыряться в носу.

Последний вариант вызова, «git checkout (-p|–patch)», пришел на замену двум длинным предыдущим командам

С чего ты взял, что git checkout --patch пришёл на замену git checkout --ours|--theirs? Это две совершенно разных операции.

Например, режима «detached head» в Mercurial нет

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

Я как раз и писал о том, что фичи по сути у ртути те же, но интерфейс к ним заметно удобнее.

С чего ты взял, что git checkout --patch пришёл на замену git checkout --ours|--theirs? Это две совершенно разных операции

Это разные команды, которые применяются для одной цели - обновления текущего измененного репозитория на определенную ревизию.

фичи по сути у ртути те же

Нет, например, detached HEAD в Git нигде не запоминается. Ты можешь попрыгать по ревизиям миллион раз и это никак не повлияет на последующую производительность репозитория. Прямого эквивалента этой фиче у ртути нет — ты показал какие-то странные псевдо-непсевдо-ветки (смысл которых от меня ускользает, ну да ладно).

интерфейс к ним заметно удобнее.

Потому что ты так сказал?

Это разные команды, которые применяются для одной цели - обновления текущего измененного репозитория на определенную ревизию.

Нет. Это разные операции, объединённые одним общим свойством — они вытаскивают какие-то данные из текущего состояния (индекса) в какие-то файлы в рабочем дереве.

От себя добавлю, что detached HEAD используется для git submodules.

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

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

Все слияния в транк только сквошем и фастфорвардом, потом там аккуратная история, на которую приятно смотреть

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

Продолжать можно упоминая убогие интерфейсы для Git, которые не давали удобных средств просмотра истории, и которые со временем все-таки перестали быть такими убогими, благодаря чему проблема «что у меня вообще тут в историях веток было?» несколько отошла на второй план.

PS: ах да, почему за rebase нужно отрывать руки. Потому что он нарушает историю правок. С таким же успехом можно ее и не хранить вовсе, что я как бы неявно упомянул в абзаце про shelve/stash.

Нет, например, detached HEAD в Git нигде не запоминается. Ты можешь попрыгать по ревизиям миллион раз и это никак не повлияет на последующую производительность репозитория

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

Это разные операции, объединённые одним общим свойством — они вытаскивают какие-то данные из текущего состояния (индекса) в какие-то файлы в рабочем дереве

Да, вытаскивают. Как ты собрался вытаскивать версии этих файлов, если у тебя есть локальные незакомиченные правки? Дай отгадаю - ты их закоммитишь, а потом сделаешь checkout. Так сделает любой человек с Post-Git Syndrome. Для всех остальных сделано git checkout -p, которое сольет правки и по необходимости запустит разрешение конфликтов.

Для всех остальных сделано git checkout -p, которое сольет правки и по необходимости запустит разрешение конфликтов.

Мне кажется, ты просто не знаешь, что делает git checkout -p %)

Мне кажется, ты просто не знаешь, что делает git checkout -p %)

Хорошо, где я ошибся в моем описании?

git checkout -p интерактивно (выборочно) применяет изменения из индекса к выбранным файлам. git checkout в этой форме вообще не меняет HEAD.

git checkout -p интерактивно (выборочно) применяет изменения из индекса к выбранным файлам. git checkout в этой форме вообще не меняет HEAD

«git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​] »
"...The chosen hunks are then applied in reverse to the working tree (and if a <tree-ish> was specified, the index)."

Конечно, если я правильно понял твоё «не меняет HEAD».

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

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

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

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

Конечно, если я правильно понял твоё «не меняет HEAD».

Судя по всему, неправильно, потому что приведённая цитата не противоречит сказанному мной :)

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

Ты описываешь процесс разработки, под который напрашивается Perforce. А Mercurial и Git в данном случае играют роль совы на глобусе — больше ничего под рукой не оказалось.

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

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

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

Тут вообще не нужно слияние веток - это простое применение патча.

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

Ты разтридварасил всю историю на локальной ветке, но аргументируешь это тем, что всё равно удалишь ее и сольешь все изменения в один коммит. Зачем тогда тебе вообще здесь rebase, если нет разницы, как ты сливаешь правки? Эта задача решается простым merge без разрушения истории, на всех трёх упомянутых SCM.

Я дополню.

Потому что он нарушает историю правок. С таким же успехом можно ее и не хранить вовсе

Историю правок нарушать можно и нужно (разумеется, только пока она ещё не опубликована). Почему, вы спросите? По одной простой причине: настоящая история правок, в которой написано, как ты два дня ковырялся в носу и 10 раз переписывал одну и ту же строчку и потом ещё три дня отлаживал тесты методом морского боя и научного тыка (поправил-запушил-получил от CI по щам-снова поправил), абсолютно никого не интересует. Ни-ко-го.

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

Разумеется, нормальные люди сразу так не пишут. Идёшь по коду — о, опечатка в комменте. О, хреново названная переменная. О, ещё какой-нибудь косяк. И ты по ходу всё это правишь и коммитишь промежуточные результаты работы, чтобы их не потерять. Разумеется, такую «историю» можно и нужно переписать и причесать перед пушем в условный мастер. И ты берёшь и делаешь интерактивный ребейз: некоторые коммиты сливаешь, некоторые редактируешь, в некоторых пишешь внятное сообщение.

Конечно, если я правильно понял твоё «не меняет HEAD».

Судя по всему, неправильно, потому что приведённая цитата не противоречит сказанному мной

«git checkout» без указания коммита или ветки не изменяет указатель HEAD. Это относится ко всем трем версиям команды:

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>…​
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…​]

Потому я не вижу, где я ошибся.

Вот здесь:

Для всех остальных сделано git checkout -p, которое сольет правки и по необходимости запустит разрешение конфликтов.

git checkout -p не сливает никакие правки и не запускает разрешение конфликтов. Равно как и два предыдущих по списку варианта — они вообще для другого, они для ручного разрешения конфликтов при мерже на уровне отдельных файлов.

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

В данном случае история правок не была нужна.

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

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

И ты берёшь и делаешь интерактивный ребейз

С таким же успехом можно делать патч в исходную ревизию с последующим слиянием с мастером. Я признаю здесь лишь то, что rebase в данном случае не отыгрывает никакой роли, ровно как и весь Git, потому по рукам за это можно не давать - да хоть индусы на папирусе записывали твои временные правки, какая разница?

Ты описываешь процесс разработки, под который напрашивается Perforce. А Mercurial и Git в данном случае играют роль совы на глобусе — больше ничего под рукой не оказалось.

Ну это типичная методика, да, я для твоего понимания описываю, а не потому, что изобрел ноу-хау.
Если тебе интересно, почему именно git - опыт его использования (в отличие от hg) у членов команды, опыт его использования у кандидатов. Ни один чувак, который приходил на интервью, не сказал, что использовал Mercurial - обычно git, иногда svn.

Mercurial и Perforce тоже позволяют создать локальные ветки, а потом отдельно их пушить. А также, все три инструмента позволяют забивать болт, вообще не трогая SCM и не создавая веток, пока сам работаешь со своими правками.

Ну и отлично. Видишь, гит не хуже.

Тут вообще не нужно слияние веток - это простое применение патча.

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

Ты разтридварасил всю историю на локальной ветке, но аргументируешь это тем, что всё равно удалишь ее и сольешь все изменения в один коммит. Зачем тогда тебе вообще здесь rebase, если нет разницы, как ты сливаешь правки? Эта задача решается простым merge без разрушения истории, на всех трёх упомянутых SCM.

Как уже верно заметили, история на локальной ветке («fix indent», «fix typo», «zarabotay uje gadina»), о которой ты так печешься, не интересна никому, кроме меня.
Rebase же в конечном счете позволяет получить в транке линейную историю цельных коммитов с красивым, внятным описанием.

git checkout -p не сливает никакие правки и не запускает разрешение конфликтов. Равно как и два предыдущих по списку варианта — они вообще для другого, они для ручного разрешения конфликтов при мерже на уровне отдельных файлов

Всё, я понял. То есть, толковых аналогов фич слияния с незакоммиченными правками, как в Mercurial, Perforce, и даже Svn, в Git просто нету, и пользователи этого замечательного инструмента вынуждены ходить раком, во веки-веков, аминь. Закапывайте.

То есть, либо куцый встроенный консольный инструмент, который неудобен и не совсем слияние делает, либо по старинке — коммитим что попало, а потом уже сливаем по-человечески через «mergetool».

Теперь я хочу услышать истории о том, что Git - лучшее решение в нынешнее время.

Ты лучше скажи, что ты хочешь сделать и зачем тебе понадобился checkout -p.

К написанному lovesan добавлю, что еще, например, в Active Oberon был атрибут процедуры REALTIME, запрещающий сборку мусора во время исполнения этой процедуры.

Но нет, там тупой Stop The World

Since go1.5 the GC has been largely concurrent but with short stw pauses at certain points in the algorithm. in 1.6,1.7 and coming up in 1.8 there have been successive improvements to improve the worst case stw times. Upper bound in 1.8 is ~100 microseconds.

Не такой уж и тупой, если задержки минимальны. Это не такой Stop The World как в питоне, где могут быть задержки в десятки секунд.

А если приложуха на Го занимает 48 гиг оперативки? Как тогда поведет себя гошный сборщик мусора?

Не такой уж и тупой,

Но тупее чем в Яве(в которой несколько алгоритмов GC реализованно) и в Mono.

Варианты, что ртуть просто меньше умеет, или что в Git более подробная справка, не рассматриваются?

Git напоминает велосипед, к которому сбоку приделали ракетные двигатели, вал и винты АПЛ, вместо седла установили томограф, а руль заменили игрушкой из секс-шопа.

sss, залогинься

git checkout -p не сливает никакие правки и не запускает разрешение конфликтов. Равно как и два предыдущих по списку варианта — они вообще для другого, они для ручного разрешения конфликтов при мерже на уровне отдельных файлов

Я понял наконец, о чем ты. Оказывается, «git checkout -p» предоставляет инструменты намного более убогие, чем таковые есть в Mercurial, Perforce, и даже SVN - во всех трёх есть автоматическое слияние с незакоммиченными правками, при этом тулза ручного слияния выпрыгивает только по конфликтам. В Git встроенная тулза вываливает вообще все правки, и в целом убога. Таким образом, Git просто не оставляет выбора, заставляя коммитить правки без необходимости на то, и дальше эти «служебные» коммиты сливать удобными инструментами.

Я хочу теперь услышать еще раз что-то вроде «мы выбрали Git, потому что это лучший инструмент для нашей задачи».

PS:

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

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

PPS: Оказался дубль-пересказ Там опять Go ругают (комментарий)
Мне почему-то показалось, что то сообщение так и не отправилось.

Если тебе интересно, почему именно git - опыт его использования (в отличие от hg) у членов команды, опыт его использования у кандидатов. Ни один чувак, который приходил на интервью, не сказал, что использовал Mercurial - обычно git, иногда svn

Ваша логика очень простая: пользоваться Git сложно, потому и остальными инструментами пользоваться сложно; мы уже знаем Git - у нас нет столько времени, чтобы изучать другие инструменты. Но вам не приходит в голову, что это один Git такой сложный, и другие аналогичные инструменты осваивать намного проще. Да, ты упомянул SVN, но у неё есть своя специфика, которая не всем подойдет.

По этой причине спрашивать о владении SCM примерно подобно тому, как спрашивать «какими текстовыми редакторами вы владеете? Emacs, Notepad++, Sublime, VSCode?» — потому что это вспомогательный инструмент, который на базовом уровне осваивается за день, и он призван просто не мешать, быть невидимым, по желанию преподнося отдельные приятные фичи. Я даже не точно знаю, в каких редакторах/IDE пишут код другие JS-прогеры в моем проекте. Да, я знаю, что кто-то использует PHP Storm, я использую Atom — но это вообще никого не колышет. Так же вчера был SVN, завтра Git — люди вообще не парятся, какая там тулза у них держит сорцы.

Mercurial и Perforce тоже позволяют создать локальные ветки, а потом отдельно их пушить. А также, все три инструмента позволяют забивать болт, вообще не трогая SCM и не создавая веток, пока сам работаешь со своими правками.

Ну и отлично. Видишь, гит не хуже

Оказывается, таки хуже:
Там опять Go ругают (комментарий)
В принципе, можно такой сценарий делать реализовывать на «stash/stash pop» (как это делаю я), но факт остается фактом - Git не дает способов просто сделать checkout в грязной репе, что довольно заметно прогибает раком разрабов и порождает пагубную моду «коммит на каждый чих».

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

hg diff > hg import

Или ты из тех, кто пишет в комментария к коммитам больше, чем самих правок, и нужно еще и объединить комменты в один большой? Результат работы rebase у тебя потерян, разве нет? Какая разница, дает ли он линейную или нелинейную историю?

Git не дает способов просто сделать checkout в грязной репе

емнип, для этого есть stash. Если я правильно понял что хочется.

Как работать с грязной репой я и mercurial плохо представляю.

Ещё разве что в hg файлы по умолчанию все коммитятся, а в git надо вручную добавлять список для коммитов.

Ну а что делает chechout (все возможности) я плохо представляю. Если ветка new не существует, то checkout new и checkout -b new разные вещи делают.

А если приложуха на Го занимает 48 гиг оперативки? Как тогда поведет себя гошный сборщик мусора?

Будут паузы порядка 100 мс. По нынешним меркам это все равно очень мало.

Ваша логика очень простая: пользоваться Git сложно, потому и остальными инструментами пользоваться сложно; мы уже знаем Git - у нас нет столько времени, чтобы изучать другие инструменты. Но вам не приходит в голову, что это один Git такой сложный, и другие аналогичные инструменты осваивать намного проще

git реально сложный, github порешал рынок. Помню когда в команде поднималась тема переезда с svn, то фактически был спор между svn vs git vs что-то другое, последнее было просто собирательным образом всех альтернатив, про git писали во всех блогах, git хостил мегапроект под названием ядро линукса, а hg… «hg - этож что-то от микрософт?» :)

Переезд происходил в 2011-2012 году.

А если приложуха на Го занимает 48 гиг оперативки? Как тогда поведет себя гошный сборщик мусора?

Будут паузы порядка 100 мс. По нынешним меркам это все равно очень мало.

Не верю, что в природе, вообще, существует такой язык с GC, не то, что Go.

Есть прямые замеры и доказательства?

Мне кажется, что там сильно возрастает алгоритмическая сложность, и все невидимые ранее коэффициенты О-большого начинают давать о себе знать.

Я понял наконец, о чем ты. Оказывается, «git checkout -p» предоставляет инструменты намного более убогие, чем таковые есть в Mercurial, Perforce, и даже SVN - во всех трёх есть автоматическое слияние с незакоммиченными правками, при этом тулза ручного слияния выпрыгивает только по конфликтам.

«Оказывается, апельсин предоставляет инструменты намного более убогие, чем автомобиль»

Таким образом, Git просто не оставляет выбора

man git checkout --merge

Повторяю для особо упорных, git checkout --patch — это другая операция для других задач. Как слышно, приём.

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

Нет, с любой точки зрения это очень близкие операции: копирование файлов из индекса в рабочее дерево.

емнип, для этого есть stash. Если я правильно понял что хочется

Да, правильно понял, я именно через stash это и делаю.

Как работать с грязной репой я и mercurial плохо представляю.

«hg update -m». Также есть Shelve и MQ.

Ещё разве что в hg файлы по умолчанию все коммитятся, а в git надо вручную добавлять список для коммитов

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

Ну а что делает chechout (все возможности) я плохо представляю. Если ветка new не существует, то checkout new и checkout -b new разные вещи делают

Только потому, что создание ветки не приводит к checkout, и потому в качестве того самого второго слоя опций вместо старых команд

git branch new
git checkout new

git checkout -b new

Помню когда в команде поднималась тема переезда с svn, то фактически был спор между svn vs git vs что-то другое, последнее было просто собирательным образом всех альтернатив, про git писали во всех блогах, git хостил мегапроект под названием ядро линукса, а hg… «hg - этож что-то от микрософт?»

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

А так-то уже в 2011 Mercurial и Bazaar были вполне зрелыми системами, не говоря уже о распрекрасной Perforce, которая уделывает их всех вместе взятых.

Мне кажется, что там сильно возрастает алгоритмическая сложность, и все невидимые ранее коэффициенты О-большого начинают давать о себе знать

Ну я примерно экстраполировал. Точные цифры для 4 Гб на 1.5 есть - там 10 мс длительность stop-the-world:
https://github.com/golang/go/issues/11485

Нет, 4Гб несерьезно, и экстраполировать так нельзя на 48 Гб!

Shelve и MQ

Какой-то из них разработчиками mercurial не рекомендуется уже пару лет.

Я знаю, что сначала создают ветку, а вот что происходит если сразу сделать git checkout new?

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

Дело привычки, вручную выносить файлы из списка включённых а коммит ненамного удобнее, всё равно сначала список изменений смотрю: мало ли в какой файл влез и забыл об этом.

Емнип, в hg по умолчанию и ветки все пушит в репу. И удалённый working directory нужно обновлять отдельно: если «удалённый» это локальный каталог, то не очень удобно, на сервере хоть настроить можно автообновление.

Но это всё просто разный подход и не более.

man git checkout --merge

Да, оно. Тогда градус ублюдочности снижается, до обычных ещё терпимых методов слияния. Однако, «git checkout --merge» при наличии прошлых конфликтов слияния перепишет содержимое файла своей версией с конфликтами. То есть, команда, которая призвана сохранить локальные правки, может с таким же успехом их уничтожить, если пользователь будет невнимателен.

Нет, с любой точки зрения это очень близкие операции: копирование файлов из индекса в рабочее дерево

Для пользователя не существует никакого индекса. Пользователь хочет получить правки такой-то ревизии, а вместо этого ты ему тыкаешь индексами, «detached HEAD», и прочим мусором.

Однако, «git checkout –merge» при наличии прошлых конфликтов слияния перепишет содержимое файла своей версией с конфликтами. То есть, команда, которая призвана сохранить локальные правки, может с таким же успехом их уничтожить, если пользователь будет невнимателен.

Нет, неправда:

$ gco -m v5.5
Makefile: needs merge
error: сначала нужно разрешить конфликты в вашем текущем индексе

Для пользователя не существует никакого индекса. Пользователь хочет получить правки такой-то ревизии, а вместо этого ты ему тыкаешь индексами, «detached HEAD», и прочим мусором.

«Для пользователя не существует никаких исходников, версий, компиляторов и прочего. Пользователь хочет просто кнопку сделать за5.1ись, а вместо этого ты ему тыкаешь всякими языками программирования и прочим мусором» :)

Как бы нет, назвался груздем — полезай в кузов.

Какой-то из них разработчиками mercurial не рекомендуется уже пару лет

Не слышал про такое. Есть расширение «Evolve» призване наменить MQ. Но Evolve пока что находится в разработке и вообще считается внешним расширением, в отличие от MQ, которое находится в штатной поставке:
https://www.mercurial-scm.org/wiki/UsingExtensions#Extensions_bundled_with_Me...

Дело привычки, вручную выносить файлы из списка включённых а коммит ненамного удобнее, всё равно сначала список изменений смотрю: мало ли в какой файл влез и забыл об этом

Не-е-е, если бы всё было так просто... В Git есть индекса, которые являются как бы снимком файла, а сам файл мог стать уже другим. В итоге у тебя три версии рабочего каталога: локальные файлы, индекс, закоммиченная версия. Для 95% пользователей Git это просто бессмысленное усложнение, которым они никогда не будут пользоваться.

Однако, «git checkout –merge» при наличии прошлых конфликтов слияния перепишет содержимое файла своей версией с конфликтами. То есть, команда, которая призвана сохранить локальные правки, может с таким же успехом их уничтожить, если пользователь будет невнимателен.

Нет, неправда:
gco -m v5.5

Я имею в виду сценарий:

~ $ mkdir test
~ $ cd test
~/test $ git init ./
~/test $ echo "v1" > Makefile
~/test $ git commit -a -m "v1"
~ $ cd ../
~ $ mkdir test2
~ $ git clone test test2
~ $ cd test2
~/test2 $ echo "v2" > Makefile
~/test2 $ git commit -a -m "v2"
~/test2 $ cd ../test
~/test $ echo "v3" > Makefile
~/test $ git commit -a -m "v3"
~/test $ git pull ../test2
From ../test2
 * branch            HEAD       -> FETCH_HEAD
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Automatic merge failed; fix conflicts and then commit the result.
~/test $ echo "ololo" >> Makefile
~/test $ grep "ololo" Makefile
ololo
~/test $ git checkout -m Makefile
Recreated 1 merge conflict
~/test $ grep "ololo" Makefile

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

«Для пользователя не существует никаких исходников, версий, компиляторов и прочего. Пользователь хочет просто кнопку сделать за5.1ись, а вместо этого ты ему тыкаешь всякими языками программирования и прочим мусором» :)
Как бы нет, назвался груздем — полезай в кузов

Если коротко одной фразой описывать проблемы Git, то можно сказать так: «он делает простые задачи сложными, при том, что большинству пользователей сложные функции никогда не понадобятся». Это относится и к возможности уничтожить репу, и к чрезмерному доступу к внутренностям, и к неудобному интерфейсу, который удобен разве что для мейнтейнеров крупного опенсорс проекта, вроде ядра Linux.

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

Есть расширение «Evolve» призване наменить MQ. Но Evolve пока что находится в разработке и вообще считается внешним расширением, в отличие от MQ, которое находится в штатной поставке:

Расширения какие-то, одно устарело, другое ещё не готово, третье сбоку от первых двух… То ли дело Git: в комплекте всё, что нужно, и ничего более. ;)

Для 95% пользователей Git это просто бессмысленное усложнение, которым они никогда не будут пользоваться.

Что ж, видимо, мне придётся использовать одну и ту же цитату дважды за один тред.

«Если вы спроектируете систему из расчёта на идиотов, то только идиоты и будут ей пользоваться».

Я имею в виду сценарий

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

Если коротко одной фразой описывать проблемы Git, то можно сказать так: «он делает простые задачи сложными, при том, что большинству пользователей сложные функции никогда не понадобятся». Это относится и к возможности уничтожить репу, и к чрезмерному доступу к внутренностям

См. предыдущее сообщение.

и к неудобному интерфейсу

Синдром утёнка detected.

люди, которые владеют разными SCM, просто не считают необходимым акцентировать на этом внимание, а те, кто кроме Git ничего не знают, бегают и везде кричат о своем навыке волшебника.

Я не знаю, кто где бегает и кричит, но это проблемы тех, кто бегает и кричит.

Вот ты, например, бегаешь и кричишь о том, что ртуть рулез, а Git какашка. Ну и чем ты лучше?

Вот ты, например, бегаешь и кричишь о том, что ртуть рулез, а Git какашка. Ну и чем ты лучше?

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

PS: Наверное git чем-то полезен, но для «одиночек» зачем он?
Что касаемо разработки проекта группой программистов, то … /далее не хочу портить себе настроение, рассуждением на эту тему/.

Владимир

Расширения какие-то, одно устарело, другое ещё не готово, третье сбоку от первых двух… То ли дело Git: в комплекте всё, что нужно, и ничего более

Ты скатываешь обсуждение в говно. Статус «расширение» просто значит функцию, которую ты можешь включать или не включать.

«Если вы спроектируете систему из расчёта на идиотов, то только идиоты и будут ей пользоваться»

Но проблема в том, что идиоты пользуются Git.

git чем-то полезен, но для «одиночек» зачем он?

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

То, что команда, призванная затирать пользовательские изменения в файлах в рабочем дереве, затирает пользовательские изменения в файлах в рабочем дереве?

Потерять все правки за последний час? Да, это нормально для Git, так запланировано.

Вот ты, например, бегаешь и кричишь о том, что ртуть рулез, а Git какашка. Ну и чем ты лучше?

Например, я лучше тем, что, в отличие от большинства пользователей Git, пользовался также иными SCM.

Да ты крут, пацанчик! Осилить vcs - это же на Нобелевку тянет.

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

Сильно все утрируете.  

Фантазер однако.
Продолжайте …

Владимир

Например, я лучше тем, что, в отличие от большинства пользователей Git, пользовался также иными SCM.

Я еще с CVS начинал, потом SVN, потом BZR, потом Git - так что это нифига не аргумент.

Продолжайте …

а смысл?

а смысл?

Смысла нет.
Ведь вы говорите совсем не о том, о чем говорил я ранее.
Расскажите еще о вашем отношении к «Война и мир».

Владимир

Да ты крут, пацанчик! Осилить vcs - это же на Нобелевку тянет

Вот именно об этом я и пишу. Осиливание SCM-тулзовины не имеет значения, потому что они изначально вообще не должны маячить на радаре. Но в Git-мире, внезапно, осиливание стало достижением. Вместо того, чтобы просто выкинуть Git и начать использовать более удобные инструменты, которые не ставят тебе палки в колеса из коробки.

Я еще с CVS начинал, потом SVN, потом BZR, потом Git - так что это нифига не аргумент

Вон, выше человек, который приводил пример конторы, где рассуждали в терминах «Git vs SVN vs всё остальное». Это не единичный случая, я сам лично знаю человека, который руководствовался мотивами вроде «я кроме Git ничего не умею».

… я сам лично знаю человека, который руководствовался мотивами вроде «я кроме Git ничего не умею».

Это главное в разработке.

Владимир

… я сам лично знаю человека, который руководствовался мотивами вроде «я кроме Git ничего не умею».

В крутых конторах тех кто не знает git и не умеет «пальцы веером заворачивать» даже на порог не пустят.

Владимир

А Вам не кажется, что при грамотном использовании любой бол-мен заточенный под данную задачу инструмент подойдет, а при неграмотном таки все будет неудобно?

Sorry /а то не правильно поймут/.

Было  

В крутых конторах тех кто не знает git и не умеет «пальцы веером заворачивать» даже на порог не пустят.

«Заворачивать пальцы» /а если три заверну?/ - могут не правильно понять.

Уточнение

В крутых конторах тех кто не знает git и не умеет «пальцы веером распускать» даже на порог не пустят.

Владимир

А Вам не кажется, что при грамотном использовании любой бол-мен заточенный под данную задачу инструмент подойдет, а при неграмотном таки все будет неудобно?

«грамотный
обладающий необходимыми знаниями в какой-либо специальной области;
выполненный в соответствии с основными требованиями данной области знаний.»

Я не знаю, что здесь значит «грамотное использование». Если у тебя есть велосипед, в котором
Там опять Go ругают (комментарий)

руль заменили игрушкой из секс-шопа

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

Ну так логично. А как без VCS разрабатывать? Да элементарно пулриквест в VCS очень удобно делается. А без этого - как?

Другое дело, что из-за того, что мелкомягкие купили гитхаб, теперь гит опорочен. И лучше бы, конечно, переходить на mercurial.

Ну так логично. А как без VCS разрабатывать? Да элементарно пулриквест в VCS очень удобно делается. А без этого - как?

Не об этом речь шла.
Вот индивидуально /не в группе программистов/, разрабатываю проекты.
Зачем мне git?

PS: Впрочем - «не все и на велосипеде на работу ездят».

Владимир

Вот индивидуально /не в группе программистов/, разрабатываю проекты. Зачем мне git?

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

А как вообще хранить все эти исходники? Не в тарболах же на яндекс-диске! Закидываем на гитхаб, битбакет, сосфорж…

Один SSD в кармане и несколько external hdd дома /очень удобно/.
Non problem!

Владимир

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

Или каждый раз перед тем, как внести изменения, делать очередной тарбол?

Или каждый раз перед тем, как внести изменения, делать очередной тарбол?

Конечно нет.
Дело привычки.
Мы не поймем друг друга.

Кстати код, который пишете для предприятия также в обменниках сохраняете?

Владимир

Конечно нет.

Sorry /вранье меня «коробит»/.

В конце дня и в течении дня делаю несколько архивов.
Когда API разработано, промежуточные архивы удаляю.
Всегда имею не менее двух копий архивов на разных носителях.
Иногда дублирую на external hdd.

Владимир

Кстати код, который пишете для предприятия также в обменниках сохраняете?

Зависит от предприятия. На всех есть частные репозитории, на BitBucket даже на бесплатном тарифе. Или же предприятие вполне может держать свой инстанс gitlab/bitbucket/you-name-it.

Зависит от предприятия. На всех есть частные репозитории, на BitBucket даже на бесплатном тарифе. Или же предприятие вполне может держать свой инстанс gitlab/bitbucket/you-name-it

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

Или каждый раз перед тем, как внести изменения, делать очередной тарбол?

Инкрементальный бэкап с ревизиями файлов, используя написанный на go restic.

Каким донным должен быть коммерс, чтобы не позволить себе поставить какое-то дешманское корыто под сервер

Так GitHub/BitBucket/etc as a service лучше чем «дешманское корыто». Плюс не надо его администрировать. Т.е. вопрос не в «донности» комерса, а в деньгах.

Блин, даже роутер на OpenWrt с флешкой

Ну для GitLab требуется 8GB RAM (https://docs.gitlab.com/ee/install/requirements.html), это чуть по более, чем роутер.

Ваша логика очень простая: пользоваться Git сложно, потому и остальными инструментами пользоваться сложно; мы уже знаем Git - у нас нет столько времени, чтобы изучать другие инструменты. Но вам не приходит в голову, что это один Git такой сложный, и другие аналогичные инструменты осваивать намного проще.

Ты упускаешь тот момент, что система контроля версий - это не только синтаксис командной строки, но и определенная идея работы с ней, ее возможности, инфраструктура - ну там разные инструменты, которые используются в связке. Git подходит требованиям, и с ним знакомы в команде? Отлично. Это на форуме можно бесконечно письками меряться, а на работе стоят конкретные задачи c конкретными сроками - за N дней перевести репозитории с SVN на что-то более подходящее, развернуть то и это, настроить, рассказать, показать, начать трудиться.

По этой причине спрашивать о владении SCM примерно подобно тому, как спрашивать «какими текстовыми редакторами вы владеете?

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

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

Так же вчера был SVN, завтра Git — люди вообще не парятся, какая там тулза у них держит сорцы.

См. выше. Ну и ты сам себе противоречишь:

Да, ты упомянул SVN, но у неё есть своя специфика, которая не всем подойдет.

Git не дает способов просто сделать checkout в грязной репе

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

порождает пагубную моду «коммит на каждый чих»

Такое чувство, будто коммитить для тебя - это как сексом заниматься, до свадьбы ни-ни. Зато бегать по дереву коммитов с грязной репой и незаконченной работой - это абсолютно нормально и богоугодно.
Отличная это мода, просто ты, как я уже сказал, не понимаешь модель Git'a, поэтому вместо того, чтобы ее использовать, пытаешься с ней бороться.

Так GitHub/BitBucket/etc as a service лучше чем «дешманское корыто». Плюс не надо его администрировать.

...и можно там же проинтегрироваться с Jira и Confluence, которые тоже не придется администрировать.

К слову, забыл об этом.

Или ты из тех, кто пишет в комментария к коммитам больше, чем самих правок, и нужно еще и объединить комменты в один большой?

Я люблю информативные описания, да, чтобы без просмотра правок было хотя бы в общих чертах понятно, для чего правки были внесены, что и как в них сделали. Что-нибудь вроде:

sfc: fix timestamp reconstruction at 16-bit rollover points

We can't just use the top bits of the last sync event as they could be
off-by-one every 65,536 seconds, giving an error in reconstruction of
65,536 seconds.

This patch uses the difference in the bottom 16 bits (mod 2^16) to
calculate an offset that needs to be applied to the last sync event to
get to the current time.

Какая разница, дает ли он линейную или нелинейную историю?

Да ориентироваться в линейной потом проще, вот и все.

Так GitHub/BitBucket/etc as a service лучше чем «дешманское корыто». Плюс не надо его администрировать. Т.е. вопрос не в «донности» комерса, а в деньгах

Администрировать - это слишком громкое слово. Аккаунты на GitHub тоже нужно «администрировать» - хотя бы просто чтобы создать их.

Ну для GitLab требуется 8GB RAM (https://docs.gitlab.com/ee/install/requirements.html), это чуть по более, чем роутер

У меня роутер с 64 Мб оперативы, 16 Мб загрузочная флешка. На нем сейчас просто веб морда и SSH, занято половину флешки. Gitolite весит еще 120 Кб. Чо там? «Our Memory Team is actively working to reduce the memory requirement»? Пусть работают, я пока подожду.

У меня роутер с 64 Мб оперативы, 16 Мб загрузочная флешка. На нем сейчас просто веб морда и SSH, занято половину флешки.

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

Это на форуме можно бесконечно письками меряться, а на работе стоят конкретные задачи c конкретными сроками

Спасибо, я в курсе методики принятия решений во многих конторах: ставится дедлайн «до конца недели», после дедлайна проходит два месяца - твоим решением до сих пор никто не пользуется. Вы ярмо себе повесили на годы, а всё потому, что кому-то показалось хорошей идеей за два дня принять решение при помощи людей, которые кроме Git и SVN ничего не знают.

https://xkcd.com/1597/

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

Да, я страдал из-за сложностей с поддержкой локальных правок в SVN. Но рак с переписыванием истории родом исключительно из Git - его нет больше нигде. Если так работать с Mercurial, то рано или поздно ты получишь вот это:
https://lostechies.com/content/jimmybogard/uploads/2011/03/image_thumb_4EE6AA...
Да, в Perforce и Mercurial возможно подражать такой работе в Git с получением аккуратной истории, но это вполне целенаправлено порицается, поскольку разрушает саму суть VCS.

Законченные промежуточные этапы я коммичу локально. Хочу напомнить, что основная задача VCS - это хранение нескольких версий. В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано. Я просто срезаю путь, и не пользуюсь Git в данном сценарии с самого начала, начиная пользоваться им там, где мне действительно нужны версии. Одной фразой мой процесс можно описать как «я просто пишу код».

Так же вчера был SVN, завтра Git — люди вообще не парятся, какая там тулза у них держит сорцы.

См. выше. Ну и ты сам себе противоречишь:

Да, ты упомянул SVN, но у неё есть своя специфика, которая не всем подойдет.

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

Git спокойно дает сделать checkout, если измененные файлы одинаковы в обеих ревизиях (в дереве коммитов, я имею в виду). Вот если файл изменялся, то выбросит ахтунг

В Git нет простых способов работать с грязным репозиторием. Игры с «git checkout» могут быстро закончиться потерей локальных изменений, потому интернет в один голос советует делать «git stash; git stash apply; git checkout». Что снова возвращает нас к убогости Git для простых задач.

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

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

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

Незаконченная работа может растягиваться на месяца, и не ясно, куда она отправится - может быть вообще в мусорную корзину. Принцип Git: закоммить - потом все равно коммит будешь удалять. Принцип Perforce/Mercurial/SVN: коммить, когда этот коммит ты будешь использовать - то ли для локальной экспериментальной версии, то ли для создания ограниченной ветки для пары разрабов, то ли для общего релиза. Лично мне ближе второй подход, потому что для меня репозиторий - не мусорная корзина, в него нет смысла что-то бросать просто для того, чтобы потом выкинуть это на свалку. Да, я понимаю, что коммитить несложно - но также я понимаю, что этот коммит все равно никто не будет использовать.

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

и можно там же проинтегрироваться с Jira и Confluence, которые тоже не придется администрировать

Жира интегрируется даже с голым Git по SSH/HTTPS/локальная сеть. Ровно как и с Mercurial и Perforce.

Я Mercurial не знаю, но бесполезные коммиты? Этож как быстрое сохранение. Я вообще теперь для работы над более менее сложной фичей завожу две ветки, черновую ветку где приходит вся работа и эксперементы, и чистовая ветка с кодом для отправки на gerrit. Конечно тут повлиял воркфлоу фирмы где я работаю, с их gerrit, но вот бесполезные коммиты, я бы сказал таких нет. На одной из прошлых работы было правило что в конце рабочего дня делать EOD коммит и пушить локальную ветку вне зависимости от законченности кода, на случай если завтра с тобой что-то случиться :)

sfc: fix timestamp reconstruction at 16-bit rollover points

We can't just use the top bits of the last sync event as they could be
off-by-one every 65,536 seconds, giving an error in reconstruction of
65,536 seconds.

This patch uses the difference in the bottom 16 bits (mod 2^16) to
calculate an offset that needs to be applied to the last sync event to
get to the current time

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

Какая разница, дает ли он линейную или нелинейную историю?

Да ориентироваться в линейной потом проще, вот и все

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

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

Бэкапы на другой машине никто не запрещал. К тому же, Git естественным образом бэкапится.

Да и вообще, роутер не такое уж и днище - это вполне себе достойный компьютер уровня 2004-2005 года, если не считать слишком уже малого кол-ва оперативной памяти DDR2-800. Что-то плана Deus Ex на подобном железе уже в 60 фпс шло (со внешней видеокартой, естественно).

Я Mercurial не знаю, но бесполезные коммиты? Этож как быстрое сохранение

Ctrl+S - вот это быстрое сохранение. Если на эту комбинацию вешать коммит, то очень быстро у тебя вырастет вавилонская башня до неба из коммитов, которые тебе не нужны и которыми ты никогда не будешь пользоваться.

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

Как нет? Ты разве используешь не исключительно последнюю версию сорцов?

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

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

А с тобой ничего не случается один хрен приходишь на работу с утра… :D

на случай если завтра с тобой что-то случиться :)

Они там слова «Централизованные бэкапы» не слышали походу

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

рак с переписыванием истории родом исключительно из Git - его нет больше нигде.

В mercurial переписывается запросто, до отправки на сервер. Да и там при желании можно разрешить. Как и в git определяется настройками сервера.

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

В Git нет простых способов работать с грязным репозиторием. Игры с «git checkout» могут быстро закончиться потерей локальных изменений

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

В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано.

Глупость какая. Не всем нужны ненужные исходники. Не говоря о том, что reflog где хранится всё что было закоммичено, если уж совсем приспичит.

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

А для кого мусорная корзина? Мне казалось, что все используют любые VCS для фиксации внесённых изменений в процессе работы. Если в твоём окружении их используют для хранения как некоторые корзину на рабочем столе, то это не проблема VCS.

Однако, Git не дает простых путей работаты с грязной репой

Так не работай с ней. Зачем самому себе проблемы создавать?

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

Не делай бесполезных коммитов и не превращай репозиторий в мусорник. PROFIT.

Мне вообще пофиг что использовать hg или git - в чём конкретный проект ведётся, в том и делаю. Разве что hg у меня всегда был в связке с tortoisehg workbench.

А если приложуха на Го занимает 48 гиг оперативки? Как тогда поведет себя гошный сборщик мусора?

stw займет около 10 мс

В mercurial переписывается запросто, до отправки на сервер. Да и там при желании можно разрешить. Как и в git определяется настройками сервера

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

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

Для этого сделано MQ, которое базируется на https://en.wikipedia.org/wiki/Quilt_(software) .

Так не занимайся такими играми, закоммить в локальную коп что успел - внесённые изменения точно не пропадут, - потом вернёшься к работе и сделаешь commit –amend

Одна из частых потребностей: выделить из сделанной за некоторый период работы часть правок, протестировать работоспособность проекта с этими правками, и релизнуть эту версию. Я очень хотел бы увидеть, как методика частых коммитов помогает упростить эту задачу. Сразу подчеркну, что в истории изменений не существует такой ревизии, которую я мог бы просто релизнуть, потому что я занимался несколькими задачами параллельно - и нет, создание 10 веток (на каждую мелкую фичу) за два месяца с последующим развлечением в их слиянии в разных комбинациях абсолютно неприемлимо. Также замечу, что я в основном корректирую именно правки, которые я сделал, то есть, вывод «git diff master...».

То есть, в случае Git я должен из моих локальных коммитов создать новую ветку, стереть в ней ненужные правки, отображаемые в «git diff master...», и дальше делать merge/rebase со squash/без. Поскольку squash+rebase является самым частым вариантом здесь, то я бы заметил, что по результату работы оно не отличается от применения патча, особенно учитывая, что автоматически собрать комментарии не получится и писать их придется ручками заново.

Теперь претензия, которую я предъявлял здесь уже несколько раз: зачем я тогда вообще создавал ветку и коммитил в нее свои правки? «hg update -m» по сути делает squash+rebase, получая тот же результат. При этом, я с тем же успехом могу дальше прыгнуть на другую ветку, потом на третью, а потом прыгнуть обратно на исходную ветку. В результате, вся операция делается за «hg update -m; hg shelve -k; правки; hg commit» либо «hg shelve -k; правки; hg update -m; hg commit» — я подчеркиваю, что здесь имеет место нулевая предварительная подготовка репозитория, я трогаю VCS только когда мне нужно.

Вторая упомянутая ранее претензия: да, Git теоретически позволяет проводить аналогичный сценарий, но в Git, как правило, это делать опасно и неудобно, и по этой причине пользующиеся Git люди вынуждены изучать наиболее простые и удобные пути работы с Git, которые как раз и сводятся к частым коммитам, rebase+squash, stash+pop и другим. Самые важные свойства VCS, на мой взгляд, — это не мешать и не терять пользовательcкие данные, и в этом плане Git весьма заметно проигрывает как Mercurial, так и Perforce. Git был создан, когда не было Mercurial и когда Perforce был платным, но в 2020 году нет ни одной причины пользоваться неудобным и опасным инструментом, когда есть более удобный и безопасный.

Не говоря о том, что reflog где хранится всё что было закоммичено, если уж совсем приспичит

Да, это резервные копии по-git-овски. Поскольку некоторые операции в Git деструктивны, то он сохраняет удаленные коммиты в reflog-е, позволяя теоретически их восстановить. Практически же в гробу я видал ваше восстановление - лучше дайте мне инструмент, который не будет заставлять меня восстанавливать потерянные данные.

Однако, Git не дает простых путей работаты с грязной репой

Так не работай с ней. Зачем самому себе проблемы создавать?

Потому что, внезапно, в SVN, Perforce, и Mercurial это делается очень просто и требует минимального взаимодействия с VCS. Чем-то напоминает: «мы раком ходим - и ты ходи. Ты что, дурак, прямо ходить? Так же упасть и лоб расшибить можно».

А если приложуха на Го занимает 48 гиг оперативки? Как тогда поведет себя гошный сборщик мусора?

stw займет около 10 мс

Сказочники!

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

Не верю! (c)

методика частых коммитов п

Хз что это такое, но отдельные коммиты переносятся в другие ветки либо создание патчей, либо chery-pick. Может ещё проще можно, у меня в git достаточно простой набор используемых команд.

Раз всё не так - не пользуйся, делов то. Что тебя так рвёт то?

Ты что, сомневаешься в моих способностях похерить свои наработки в локальной репе на меркуриал?

И меня интересует не среднее, не персентиль

The new version of Go reduces our 95-percentile garbage collector from 279 milliseconds down to just 10 ms. link

Это было про релиз Go 1.5. С тех пор были еще доработки по GC.

Nearly all STW pauses in Go are really sub-millisecond ones. If you look more real-life test case (see e.g. this file), you’ll notice that 16GB static set on a ~ regular 16-core server implies your longest pause = 50ms (vs 5s for .NET), and 99.99% of pauses are shorter than 7ms (92ms for .NET)! link

Эта статья от сентября 2018, так что тоже данные не самые свежие. Но там есть ссылка на гитхаб с бенчмарком - ты всегда можешь перепроверить.

Хз что это такое, но отдельные коммиты переносятся в другие ветки либо создание патчей, либо chery-pick. Может ещё проще можно, у меня в git достаточно простой набор используемых команд

cherry-pick всей ветки = rebase

Однако, переносить мне нужно не цельные коммиты, а их куски.

Раз всё не так - не пользуйся, делов то. Что тебя так рвёт то?

Напоминаю:

Повторишь это, когда наберешь написанную на Си команду гита, чтобы запушить новые строчки на Расте

Гит - редкостный кусок дерьма, слепленный на коленке по мотивам проприетарного софта. Лично я предпочитаю Hg

Более того, в самом сообществе понимают необходимость переделки Git, но проблема в том, что сделать ее с сохранением обратной совместимости не получится. Потому я и пишу, что Git — это пример плохого софта. Не то, чтобы автор потирая ручки сидел и думал «какую бы гадость сообществу сделать? А напишу-ка я инструмент для контроля ревизий, которым будут все пользоваться для разработки софта и страдать при этом». Нет, ему просто было всё равно, его больше волновало, что халяву с Perforce закрыли — вот он сел и написал, тупо для себя.

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

Ты что, сомневаешься в моих способностях похерить свои наработки в локальной репе на меркуриал?

Там тоже есть веселые команды, но в основном он сделан так, что минимизирует возможности пользователя потерять свои правки. Git же отличается тем, что содержит неочевидные, коварные способы потерять нажитое непосильным трудом. Да, оба инструмента содержат reflog, но это уже для любителей глубокого проникновения.

cherry-pick всей ветки = rebase

ветка ж отдельная и специально создана для экспериментов, не всё ли равно?

Однако, переносить мне нужно не цельные коммиты, а их куски.

Я в таких случаях стараюсь делать коммиты более атомарными. Но тут всё от личных привычек зависит.

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

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

Я в таких случаях стараюсь делать коммиты более атомарными. Но тут всё от личных привычек зависит

Знал бы прикуп — жил бы в Сочи. Я никогда не могу заранее угадать, что выйдет из моих правок. Аккуратные ветки с разделенными правками и безупречными коммитами бывают только в книжках — там же, где и замечательные иерархии классов с безупречной расширяемостью. В реальном мире разработка регулярно приходит к «что у нас есть, и что можно с этим сделать?». Порой возникновение ветки можно предугадать, а порой — нет. Порой во время коммита можно разделить изменения на логические сущности, а порой оказывается, что это разделение было неправильным, и теперь ветки нужно перекраивать. Мой подход очень простой: не рыпаться без нужды на то; не принимать решения, когда не имеешь ориентиров; отсутствие архитектуры лучше ошибочной архитектуры.

Хотите пользоваться Git-репозиторием для бэкапов — хорошо, мне нравится идея. Правда, к VCS она отношения не имеет. Если же я начинаю пользовать VCS, то я должен задаться вопросом «чем мой инструмент удобнее груды патчей?».

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

Спасибо, я в курсе методики принятия решений во многих конторах: ставится дедлайн «до конца недели», после дедлайна проходит два месяца - твоим решением до сих пор никто не пользуется. Вы ярмо себе повесили на годы, а всё потому, что кому-то показалось хорошей идеей за два дня принять решение при помощи людей, которые кроме Git и SVN ничего не знают.

Не драмазитируй, не в театре.
На Mercurial смотрели, но, так сказать, при прочих равных... С SVN переехали, т.к. там стали очевидными некоторые недостатки, которые для нас были критичными (в частности svn externals), а если сравнивать Git и Mercurial, то лично я не вижу, в чем бы последний превосходил. То, о чем ты говоришь - это больше вопрос привычных тебе команд, привычного workflow и личных предпочтений.

Да, я страдал из-за сложностей с поддержкой локальных правок в SVN. Но рак с переписыванием истории родом исключительно из Git - его нет больше нигде. Если так работать с Mercurial, то рано или поздно ты получишь вот это:

Тебе не приходило в голову, что проблемы, которых ты опасаешься, возникают не из-за Git, а из-за особенностей Mercurial и того, что вы эти особенности переносите на другие VCS?

Смотри: https://ibb.co/mB8wTFR. Утрированный пример на коленке, но примерно так и обстоят дела - по крайней мере с теми ветками, которые имеют историческое значение.

Законченные промежуточные этапы я коммичу локально.

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

Хочу напомнить, что основная задача VCS - это хранение нескольких версий. В сценарии со squash/rebase Git не выполняет роль VCS, поскольку теряет версии исходников, и по этой причине его применение не оправдано. Я просто срезаю путь, и не пользуюсь Git в данном сценарии с самого начала, начиная пользоваться им там, где мне действительно нужны версии. Одной фразой мой процесс можно описать как «я просто пишу код».

Каким образом он их теряет-то?
Rebase просто закидывает твои правки на самый верх, объединяя их с правками других разработчиков. Ну, допустим, смержишь ты их без него - конечный результат тот же, только правки не наверху, а разбросаны по времени.
Допустим, мержишь ты без squash - конечный результат тот же, но правки опять же размазаны по дереву.
Если принципиально хочется сохранить оригинальный стейт, то заведи еще одну локальную ветку до rebase, хотя единственный смысл, который я вижу в подобном действии - это «в моей ветке все работает, в мастере нет, вы виноваты сами», «смотри, я закоммитил у себя раньше, поэтому исправлять должен ты» или «работали вместе, коммитил он, пусть он и отвечает». Пардон, но в нормальном, адекватном коллективе такого говна быть не должно.

В Git нет простых способов работать с грязным репозиторием. Игры с «git checkout» могут быстро закончиться потерей локальных изменений, потому интернет в один голос советует делать «git stash; git stash apply; git checkout». Что снова возвращает нас к убогости Git для простых задач.

Еще раз: команда git checkout не сработает только тогда, когда версия какого-то из «грязных» файлов в текущей точке отличается от его версии в той точке, куда ты переключаешься. Причем она не потрет твои данные, не отформатирует жесткий диск, а напишет черным по белому или белым по черному, с какими конкретно файлами проблемы. Такое чувство, будто ты сейчас пересказываешь байки в духе «один мой товарищ слышал такую историю, дело, значит, было так...» Я даже начинаю сомневаться, что ты всерьез использовал Git, а не начитался страшилок в Интернете.

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

Незаконченная работа может растягиваться на месяца, и не ясно, куда она отправится - может быть вообще в мусорную корзину. Принцип Git: закоммить - потом все равно коммит будешь удалять. Принцип Perforce/Mercurial/SVN: коммить, когда этот коммит ты будешь использовать - то ли для локальной экспериментальной версии, то ли для создания ограниченной ветки для пары разрабов, то ли для общего релиза.

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

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

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

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

Категорически не согласен. Если у коммита информативное описание, то есть высокая вероятность, что я еще на стадии его чтения пойму, заглядывать мне в этот коммит (т.е. разбираться в коде) или нет.

отличные статьи, по которым видно что маленькие паузы даются ценой:

1. в 10 раз меньшей скорости аллокации
2. невозможностью заиспользовать даже 75% выделенной кучи (процесс тупо крешится) под нагрузкой

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

Ну и про скорость аллокации - есть способы влияние этой проблемы уменьшить, например, sync.Pool.

если сравнивать Git и Mercurial, то лично я не вижу, в чем бы последний превосходил. То, о чем ты говоришь - это больше вопрос привычных тебе команд, привычного workflow и личных предпочтений.

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

Объективно Git требует больше команда для выполнения тех же действий и/или эти команды опаснее/неудобнее, чем в том же Mercurial; Git искажает рабочий цикл, требуя программиста подстраиваться под инструмент, а не инструмент подстраиваться под программиста.

Тебе не приходило в голову, что проблемы, которых ты опасаешься, возникают не из-за Git, а из-за особенностей Mercurial и того, что вы эти особенности переносите на другие VCS?

В Mercurial точно так же можно тереть ветки и перебазировать изменения, просто тогда рабочий цикл по сложности приближается к Git, с шансом накосячить и потом сидеть перекраивать репу.

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

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

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

Зачем вам VCS вообще? По твоим высказываниям у меня складывается ощущение, что вы используете его для компактирования резервных копий и релизных версий, типа чтобы не отдельными папками хранить, а экономить место, объединяя общие куски файлов. Я, например, использую историю версий, чтобы проанализировать как менялся код, чтобы в том же русле его дальше менять (в том числе свой), откуда возникла бага, на каких версиях она проявляется. Если в текущей версии проявилась трудноуловимая бага, а на прошлых версиях ее не было - почему ее не было? Если я сделал rebase, то сделать этого я уже не смогу - я потерял историю разработки, поскольку локальный прогресс разработки был в совершенно другой ветке.

Еще раз: команда git checkout не сработает только тогда, когда версия какого-то из «грязных» файлов в текущей точке отличается от его версии в той точке, куда ты переключаешься. Причем она не потрет твои данные, не отформатирует жесткий диск, а напишет черным по белому или белым по черному, с какими конкретно файлами проблемы

git checkout c файлами в качестве аргументов работает так же, как в человеческих инструментах работает команда revert. И ничего оно не пишет, ни о чем не предупреждает - просто тихо затирает твои правки.

Я даже начинаю сомневаться, что ты всерьез использовал Git, а не начитался страшилок в Интернете

И Mercurial не пользовался, и Git — я просто дворником работаю, в курилке от прогеров баек наслушался.

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

Почему Rust не используют для микроконтроллеров и новых RTOS типа Zephyr?

Почему Rust не используют для микроконтроллеров и новых RTOS типа Zephyr?

вангую ответ типа «да кому оно нужно это говно! совать наш прекрасный (системный) ЯП во всякое непотребство? не для тебя цветочек цвел!»

есть вторая версия - «перенесут llvm и мы волшебным образом туда переедем» (нет) «была охота бодаться со всякой низкоуровщиной. раст системный же!» (логично, чо) .

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

Почему не используют? Используют. https://github.com/rust-embedded/msp430-rt и т.п. Насчёт Zephyr спрашивайте авторов.

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

С таким же успехом можно ее и не хранить вовсе, что я как бы неявно упомянул в абзаце про shelve/stash.

Shelve/stash не очень хорошо работает с ревью кода. Чтоб отправить код на ревью, мне нужно его закомитить в ветку. А после ревью обычно нужно вносить новые правки, т. е. новый коммит. И итераций ревью может быть больше чем одна.

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

Мне лично ребейз тоже не нравится, но скваш коммитов вполне себе норм.

а есть RTOS на расте?

Объективно Git требует больше команда для выполнения тех же действий и/или эти команды опаснее/неудобнее, чем в том же Mercurial; Git искажает рабочий цикл, требуя программиста подстраиваться под инструмент, а не инструмент подстраиваться под программиста.

Объективно там примерно тот же самый набор команд, но плюс дополнительные ключи/команды, которые никто не призывает использовать.

В Mercurial точно так же можно тереть ветки и перебазировать изменения, просто тогда рабочий цикл по сложности приближается к Git, с шансом накосячить и потом сидеть перекраивать репу.

Возможно, в Mercurial так действительно делать не стоит, но при чем тут Git?

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

Замечательно. У нас уже есть рабочий инструмент для хранения кода с развернутым резервированием, но мы все равно будем каждые полчаса запускать rsync, закидывая сорцы на FTP, или сделаем каждой собаке по рейду.
По-моему, это у тебя нет нормального понимания, зачем тебе нужна VCS, раз ты выдумываешь костыли на рабочем месте, решая проблему, которая уже решена. Да и зачем тебе RAID? Вдруг написанный тобой код окажется бесполезным - сразу в топку его, сэкономишь итерации.

Зачем вам VCS вообще? По твоим высказываниям у меня складывается ощущение, что вы используете его для компактирования резервных копий и релизных версий, типа чтобы не отдельными папками хранить, а экономить место, объединяя общие куски файлов. Я, например, использую историю версий, чтобы проанализировать как менялся код, чтобы в том же русле его дальше менять (в том числе свой), откуда возникла бага, на каких версиях она проявляется. Если в текущей версии проявилась трудноуловимая бага, а на прошлых версиях ее не было - почему ее не было? Если я сделал rebase, то сделать этого я уже не смогу - я потерял историю разработки, поскольку локальный прогресс разработки был в совершенно другой ветке.

Собственно, для того же, для чего и тебе.
Вот буквально месяц назад у нас была трудноуловимая бага, которую можно было поймать на последнем релизе, но нельзя было вопроизвести три релиза назад. Я посмотрел разницу между двумя релизами, на что-то обратил внимание сразу (спасибо информативным описаниям коммитов), потом еще погонял бисект, нашел еще связанную проблему, исправил. Все то же самое.
Сейчас я наконец убедил команду развернуть Дженкинс и смогу в таком случае вообще использовать daily builds, т.к. , буду знать, откуда они собраны. А все почему? Потому что история в релизных ветках и вообще ветках, которые будут использоваться для сборок (e.g. master), история никогда не переписывается, и никто в здравом уме ее переписывать не станет.
Я вживую Mercurial не использовал, поэтому не в курсе, как там точно все устроено, но у меня есть подозрение, что твои переживания вызваны его особенностями и что там от rebase в сторонней ветке действительно вся репа поедет по одному месту. Тем не менее, это нюансы Mercurial, Git тут не при чем, повторюсь.

git checkout c файлами в качестве аргументов работает так же, как в человеческих инструментах работает команда revert. И ничего оно не пишет, ни о чем не предупреждает - просто тихо затирает твои правки.

Во-первых, это кейс, отличный от того, который мы обсуждали (уточнял в самом начале). Я понимаю, что ты все-таки решился прочитать документацию, но переобуваться не комильфо.
Во-вторых, нет, не revert. Эта команда приводит файл к состоянию на указанной ревизии, и только если ревизия не указана, то используется текущий HEAD. Довольно удобная вещь, кстати.
В-третьих, она делает ровно то, что написано в документации. Если в другой системе версий такая команда работает тоже по-другому, то это в общем-то ничего не значит, если только мы не начинаем рассматривать «в Mercurial иначе, а потому Git плохой» как аргумент. Но мы не станем.

И Mercurial не пользовался, и Git — я просто дворником работаю, в курилке от прогеров баек наслушался.

Без понятия, кем ты работаешь - может, и дворником, но ощущение, будто Git использовал постольку-поскольку и гуглишь сейчас статьи «git vs hg» или «why git is so bad». Знаешь,я могу еще аргументов подкинуть: ну, например, в Git-сообществе merge requests принято называть pull requests - вот ведь сволочи, делают все, чтобы запутать честного человека.

Ничего не бывает бесплатно

Спасибо, капитан.

есть способы влияние этой проблемы уменьшить, например, sync.Pool.

Они не работают в 90% случаев.

Объективно там примерно тот же самый набор команд, но плюс дополнительные ключи/команды, которые никто не призывает использовать

Да, объективно и у жигулей, и у лексуса четыре колеса и руль. Значит, машины по сути одинаковы.

В Mercurial точно так же можно тереть ветки и перебазировать изменения, просто тогда рабочий цикл по сложности приближается к Git, с шансом накосячить и потом сидеть перекраивать репу

Возможно, в Mercurial так действительно делать не стоит, но при чем тут Git?

Как ты думаешь, откуда на рынке труда столько индусов, специализирующихся на починке и администрировании Git-реп?

У нас уже есть рабочий инструмент для хранения кода с развернутым резервированием, но мы все равно будем каждые полчаса запускать rsync, закидывая сорцы на FTP, или сделаем каждой собаке по рейду

Какие преимущества Git дает над ручным резервным копированием? В чем разница между запуском «rsync -avz» и «git add; git commit; git push»? Как по мне — rsync попроще будет, и при этом тоже не требует полного копирования содержимого, а передает только разницу, хоть и менее эффективно, чем Git. Зато большие файлы удобнее через rsync бэкапить.

Да и зачем тебе RAID? Вдруг написанный тобой код окажется бесполезным - сразу в топку его, сэкономишь итерации

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

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

Я предпочитаю не читать документацию, в значительной степени повторяя историю персонажей упомянутого комикса: https://xkcd.com/1597/

Это неспроста — команды Git действительно нелогичны и неочевидны, потому нужны неординарные усилия, чтобы наконец понять их смысл и последствия. Для меня это уже определение плохого инструмента VCS. По этой причине при работе с Git я стараюсь пользоваться ограниченным набором самых простых команд, которые с большой долей вероятности дадут мне более-менее приемлимый результат. И такой подход считается нормой для Git — даже в комиксе это нашло отображение.

она делает ровно то, что написано в документации. Если в другой системе версий такая команда работает тоже по-другому, то это в общем-то ничего не значит, если только мы не начинаем рассматривать «в Mercurial иначе, а потому Git плохой» как аргумент. Но мы не станем

Просто показательно, что в Git команда «сохранить работу» имеет незначительные отличия от команды «уничтожить работу».

в самом сообществе понимают необходимость переделки Git

В каком таком сообществе?

Например: https://felipec.wordpress.com/2014/05/29/git-v2-0-0/

В чем разница между запуском «rsync -avz» и «git add; git commit; git push»? Как по мне — rsync попроще будет, и при этом тоже не требует полного копирования содержимого, а передает только разницу, хоть и менее эффективно, чем Git. Зато большие файлы удобнее через rsync бэкапить.

У меня несколько раз в жизни случалось что приложение перезаписывало файл в 0 байт, потому нужен бекап с версиями и историей.

Это какое-то говно мамонта, новость 2014 года. Git от версии 1 к версии 2 не так уж сильно изменился. Сейчас уже 6 лет версия 2.x, и тоже никаких значительных изменений (я не говорю об улучшениях, их полно) не было в командах и т.д.

Это какое-то говно мамонта, новость 2014 года. Git от версии 1 к версии 2 не так уж сильно изменился. Сейчас уже 6 лет версия 2.x, и тоже никаких значительных изменений (я не говорю об улучшениях, их полно) не было в командах и т.д

Вот именно. Статья именно о том, что Git недостаточно изменился и содержит ссылки на то, чего в нем не хватает. Я понимаю, что на ЛОР-е есть традиция не ходить по ссылкам — я могу сам сделать это за вас, но статьи читать я за вас не смогу:

https://felipec.wordpress.com/2014/06/05/whats-missing-in-git-v2-0-0/
https://www.survs.com/results/QPESOB10/ME8UTHXM4M — Git User’s Survey
- user-interface: 3.25
- documentation: 3.22
- tools (e.g. GUI): 3.01
- more features: 2.41
- portability: 2.34
- performance: 2.28
- community (mailing list): 1.70
- localization (translation): 1.65
- community (IRC): 1.65

The fact of the matter is that in every release of Git, there is only one focus: performance. Despite the fact that it’s #6 in the list of concerns of users, Git developers work on this because that’s their area of expertise, because it’s fun for them, and because they get paid to do so. There are occasional new features, and a bit of portability now and then, but for the most part Windows support is neglected in Git, which is why the msysgit project was born.

The documentation will always remain cryptic, because for the developers, it’s not cryptic, it’s very clear. And the user-interface will never change, because the developers don’t like change.

If you don’t believe me look at the backwards-incompatible changes in Git v2.0.0, or in fact, try to think back to the last time Git changed anything. Personally other than the git-foo -> ‘git foo’ change in v1.6.0 (which was horribly handled), I can’t think of anything but minor changes.

Да, объективно и у жигулей, и у лексуса четыре колеса и руль. Значит, машины по сути одинаковы.

В такой аналогии у Mercurial нет ни колес, ни руля, ни прикуривателя - они ставятся отдельными расширениями.

Как ты думаешь, откуда на рынке труда столько индусов, специализирующихся на починке и администрировании Git-реп?

Без понятия, ни разу не пользовался их услугами. Что, таких чуваков много? Ну, наверное, коррелирует с популярностью Git - в конце концов, любую VCS надо разворачивать и мало-мальски в последствии администрировать. Я надеюсь, что и у вас кто-то следит за работоспособностью серверов с Mercurial, а то мало ли что.

Какие преимущества Git дает над ручным резервным копированием?

Эффективность, сам же сказал. Плюс мой «бэкап» доступен сразу и всем посредством VCS, так что я могу, например, делегировать свою задачу другому разработчику, пока решаю свои насущные технические проблемы. Да и зачем мне rsync, когда он у меня уже как бы есть?
Тебе не нравится использовать две команды для одного действия, но почему-то не смущает использовать для него два разных инструмента.

«git add; git commit; git push»?

В общем случае «git commit -a; git push». Можешь макрос сделать, будет совсем быстро и коротко.

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

Во-первых, ты подменяешь понятия, т.к. мы говорим о работе с сорцами, а не о хранении коллекции порно.
Во-вторых, правка конфигов - это действие, которое, как правило, выполняется один раз, поэтому нет смысла регулярно сливать куда-то бэкапы с настройками софта, одного раза тоже достаточно.
В-третьх, документы и БД априори должны лежать на сервере, а не на локальном ПК. Собственно, ты сам сейчас говоришь про Perforce, и я не понимаю, при чем тут тогда RAID, rsync и прочая канитель на твоем компьютере.

Я предпочитаю не читать документацию, в значительной степени повторяя историю персонажей упомянутого комикса: https://xkcd.com/1597/

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

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

То VCS у тебя можно освоить за день, то это внезапно превратилось в неординарную задачу. Определись, что ли.
Хотя мне нравится, как ты подчеркиваешь это свое «действительно» - будто бы все всем уже объяснил и доказал.

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

Я тебе больше скажу, при повседневной работе с VCS большинство набирает в консоли только набор простых и часто используемых команд, и это множество функций в Git отличается от множества функций в Mercurial или SVN только парой-тройкой дополнительных опций. Остальное в документации Git - это advanced usage.
Я не вижу в этом никакой проблемы, т.к. любое ПО или средство для его написания обычно предоставляют больше функционала, чем тебе нужно для решения конкретной задачи, и куда хуже, когда какой-то возможности внезапно недостает, чем когда этих возможностей в избытке.

Просто показательно, что в Git команда «сохранить работу» имеет незначительные отличия от команды «уничтожить работу».

Просто нужно понимать, что checkout в Git - это не «сохранить» и не «уничтожить», а «привести к определенному состоянию». Меняется не назначение, а объект, с которым работает команда. Если понимаешь, то все встает на свои места.

В такой аналогии у Mercurial нет ни колес, ни руля, ни прикуривателя - они ставятся отдельными расширениями.

У Mercurial неотрывно от ядра существуют как минимум команды «annotate bisect branch clone commit diff log merge pull push rename revert update», и даже «serve», которое запускает встроенный веб сервер. Одна из причин, почему у Git такой отвратительный пользовательский интерфейс — потому что Git нерасширяем.

Плюс мой «бэкап» доступен сразу и всем посредством VCS

Что значить «доступен сразу и всем»? Он должен скачать изменения с сервера. С таким же успехом я могу говорить, что «доступен сразу и всем» — это когда любой может принести флешку и я ему туда скопирую новую версию проекта.

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

Каких еще два инструмента для одного действия?

В общем случае «git commit -a; git push». Можешь макрос сделать, будет совсем быстро и коротко

Тема, на самом деле, вполне годная, и можно в крон засунуть какой-то скрипт, который проверяет, что локальный репозиторий сейчас не разломан, что выбрана нужная ветка, и можно делать commit-push. Правда, мне до сих пор не встречались упоминания того, что кто-то подобным образом использовал Git - обычно все-таик люди предпочитают резервное копирование с полным сохранением всего состояния.

В-третьх, документы и БД априори должны лежать на сервере, а не на локальном ПК. Собственно, ты сам сейчас говоришь про Perforce, и я не понимаю, при чем тут тогда RAID, rsync и прочая канитель на твоем компьютере

rsync - это средство для эффективной синхронизации между компьютерами. Там уже не важно, кто из этих компьютеров клиент, а кто - сервер. БД и документы должны лежать и на серверах, и на клиентах, потому что даже 100 Мб постоянно гонять по сети туда-сюда не есть прикольно.

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

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

Это неспроста — команды Git действительно нелогичны и неочевидны, потому нужны неординарные усилия, чтобы наконец понять их смысл и последствия

То VCS у тебя можно освоить за день, то это внезапно превратилось в неординарную задачу. Определись, что ли

VCS можно освоить за день, если это не Git. Это же написано и в сообщении, на которое ты отвечаешь.

Я тебе больше скажу, при повседневной работе с VCS большинство набирает в консоли только набор простых и часто используемых команд, и это множество функций в Git отличается от множества функций в Mercurial или SVN только парой-тройкой дополнительных опций. Остальное в документации Git - это advanced usage

Мы снова возвращаемся к вопросу «зачем вообще здесь нужен Git?». Если человек в твоем сценарии все равно пользуется только ограниченным набором команд, а при любых проблемах просто делает «git diff ... > ~/backup.patch; rm -rf; git clone» и идёт по второму кругу.

Просто нужно понимать, что checkout в Git - это не «сохранить» и не «уничтожить», а «привести к определенному состоянию». Меняется не назначение, а объект, с которым работает команда. Если понимаешь, то все встает на свои места

Да, всё становится ясно после прочтения исходных кодов Git и разбора внутренних структур.

Кстати, набрел на мнение одного человека в интернете, которое подозрительно похоже на мое впечатление:

https://www.reddit.com/r/programming/comments/2fn4r9/how_to_work_with_git_flo...

After 12 months I could administer an SVN repository with ease. At 2 years I could modify and rebuild a broken repository with panache. With CVS it took a little over a year before I could use VI to fix a broken repo. Let me repeat that: Hand editing the storage files to fix a busted repository. Successfully.

I've been using Git for almost 3 years now. At 2 years I was still afraid of my own shadow. I can help people debug a screwed up local branch, but I still can't fix much once it's pushed.

Most of us need something simpler. Even if that means fewer «features». Or perhaps that's precisely it: we need something less functional and therefore less confusing.

Чем тебя Git не устраивает? Лично твои проблемы так и останутся лично твоими. Пойми уже, что это средство обмена кодом (с другими людьми, если что), и какие-то дрочённые команды, которые нужны только тебе, не заставят всю команду, даже если она условна, переходить. Барьер у Git наименьший. Вот и всё.

Барьер у Git наименьший. Вот и всё

Барьер чего?

Барьер чего?

Извини, имею ввиду т.н. порог вхождения.

Для простых смертных, которым как правило нужен только clone. Для смертных посложнее, которым нужен ещё и checkout, commit и push и может быть настроить (скопипастить) .gitconfig. И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик.

Остальное – это уже для очень ограниченного числа людей. И при любом раскладе это имеет вид пирамиды – т.к. чем «сложнее» люди – тем их меньше. И значит считаться им нужно с бо́льшим кол-вом людей. Можно что-то изменить – но только так, чтобы «внизу» ничего не ухудшилось. Иначе просто не прокатит. Таков расклад. Для git есть очень много how to в том числе и на родных языках. И в целом он очень прост – именно для вот этих нескольки команд – commit, push (фаст-форвард).

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

Для простых смертных, которым как правило нужен только clone. Для смертных посложнее, которым нужен ещё и checkout, commit и push и может быть настроить (скопипастить) .gitconfig. И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик

«Сложные» смертные — это все люди, которые изменяют содержимое Git-репозитория, а не просто делают «git clone» или «git reset --hard; git pull». Он внёс правки, внёс кто-то еще — вот и привет, их уже нужно как-то сливать. И в итоге получается, что минимальный набор команд уже оказывается весьма и весьма солидным — даже неприятно солидным для тех функций, которые с его помощью нужно выполнятиь.

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

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

«Сложные» смертные — это все люди, которые изменяют содержимое Git-репозитория

Ага, «git push – это сложно». А я и не заметил.

Он внёс правки, внёс кто-то еще — вот и привет, их уже нужно как-то сливать.

Обычно всё сливается автоматом. В иных случаях для этого есть GUI. И уж точно не нужен веб-сервер и bisect. Это проблема организации людей. Если устраивать котовасию, то разумеется её придётся разгребать. Только система контроля версий тут причём?

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

Это справедливо только если ты из прошлого века.

 $ git push ../test
To ../test
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '../test'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Дальше что? Сделать «pull»? Окей:

$ git pull  ../test
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From ../test
 * branch            HEAD       -> FETCH_HEAD
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Automatic merge failed; fix conflicts and then commit the result.

Дальше какие указания? Какие следующие простейшие команды я должен выполнять? Checkout, commit, или push?

Я подчеркиваю, что это обычно самая-присамая первая и частая проблема, с которой сталкивается любой человек, вносящий правки в Git. Да, я-то спустя полгода работы с Git научился, что нужно делать «git mergetool», а потом «git commit; git push».

Сразу второй тур запощу:

$ git push ../test
To ../test
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '../test'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushin
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Начало не предвещает беды.

$ git pull ../test
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../test
 * branch            HEAD       -> FETCH_HEAD
error: Your local changes to the following files would be overwritten by merge:
        Makefile
Please commit your changes or stash them before you merge.
Aborting

Что тут у нас? Но я не хочу вносить эти локальные правки из Makefile в общую репу. Мне можно, конечно, вручную сделать резервную копию моих файлов — однако, в таком случае я предпочту выкинуть Git и распространять исходники в тарболах, потому что трудоемкость примерно сравнимая. Но я все-таки предпочел использовать git — хорошо, будем через stash всё делать. Окей, гуглим руководства по использованию stash, которое снова не входит в золотой набор «checkout, commit, push».

$ git stash
Saved working directory and index state WIP on master: 4dbc60c Merge ../test

$ git pull ../test
From ../test
 * branch            HEAD       -> FETCH_HEAD
Merge made by the 'recursive' strategy.
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git stash pop
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
The stash entry is kept in case you need it again.

$ git mergetool
Merging:
Makefile

Normal merge conflict for 'Makefile':
  {local}: modified file
  {remote}: modified file
...

Здесь я смухлевал, потому что я использовал еще и «git status», иначе я бы запушил в репу черт пойми что:

$ git status
On branch master
Your branch is ahead of 'origin/master' by 9 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   Makefile

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        Makefile.orig

$ git reset Makefile
Unstaged changes after reset:
M       Makefile

Ой, я же забыл запушить:

$ git stash
Saved working directory and index state WIP on master: d2b176a Merge ../test

$ git push ../test
Enumerating objects: 17, done.
Counting objects: 100% (17/17), done.
Delta compression using up to 2 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (9/9), 987 bytes | 493.00 KiB/s, done.
Total 9 (delta 1), reused 0 (delta 0)
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
remote:
remote: You can set the 'receive.denyCurrentBranch' configuration variable
remote: to 'ignore' or 'warn' in the remote repository to allow pushing into
remote: its current branch; however, this is not recommended unless you
remote: arranged to update its work tree to match what you pushed in some
remote: other way.
remote:
remote: To squelch this message and still keep the default behaviour, set
remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ../test
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '../test'

Опача. Вот и приехали. А оба репозитория чисты, тем временем.

Дальше что? Сделать «pull»? Дальше какие указания?

Всего-то надо научиться в ветки. И это просто. И это и есть тот путь, которым следует выполнять подобное всё.

git push ../test master:my-feature-x

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

Всего-то надо научиться в ветки. И это просто. И это и есть тот путь, которым следует выполнять подобное всё

А кто потом это говно будет разгребать? Даже cherry_boy, наверное, не согласится с подходом «создаем отдельную ветку на каждый чих», тем более, что он тоже вряд ли знает какие-то простые пути (одна-две команды), которые позволили бы не превратить историю ревизий в миску с лапшой.

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

Может быть, ты удивишься, но такой проблемы вообще не существует в Mercurial. Как и целой кучи других проблем.

git stash push
git pull
git stash pop
<resolve conflicts if any>
git add ./
git commit
git push

И? И где здесь простота? Это уже сценарий «сложного» человека, которых как бы меньшинство, но на самом деле это большинство пользователей git, вынужденных с этим мусором возиться на регулярной основе.

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

«создаем отдельную ветку на каждый чих»

Ветка – это всего лишь файл сожержаший SHA1-хэш. Ничего сокрального в ветке нету. Создавай и сливай сколько хочешь. И всегда можно переключиться. Алиа́сь, если лень или скриптуй. Не проблема.

И? И где здесь простота? Это уже сценарий «сложного» человека, которых как бы меньшинство, но на самом деле это большинство пользователей git, вынужденных с этим мусором возиться на регулярной основе.

Ну так это ты хочешь всё усложнить. Вообще-то никто так не делает. В некоторых случаях проще вытолнкуть в stash. Вот тебе и пример. Всё логично.

P.S.: Как раз, если бы это делалось одной командой – это было бы сложно. Т.к. все шаги нужно было бы держать в голове. И в случай поломки думать на каком этапе всё отвалилось.

Ветка – это всего лишь файл сожержаший SHA1-хэш. Ничего сокрального в ветке нету. Создавай и сливай сколько хочешь. И всегда можно переключиться. Алиа́сь, если лень или скриптуй. Не проблема

Мне кажется, что ты забыл свои собственные слова:

И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик.
Остальное – это уже для очень ограниченного числа людей. И при любом раскладе это имеет вид пирамиды – т.к. чем «сложнее» люди – тем их меньше

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

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

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

Mercurial? SVN? Perforce? Упомянутый выше Bitkeeper? Или какие альтернативы имелись в виду?

Они не работают в 90% случаев.

Очень смелое заявление. А у меня противоположные данные.

Не простой тул, но git это не только сам git, а еще и github, и gitlab, исходники всяких нужных проектов.

Всего N лет назад разные проекты использовании разные VCS, у одно это bazzar, другого svn, у третьего mercular, разве от этого было проще? Надо было знать CLI всех этих тулов, хотяб чтоб скачать исходники, найти изменения в истории, понять концепцию используемого бранчинга в конкретном VCS чтоб знать где искать.

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

Вообще всё делается через ветки.

git co -b my-feature-x
touch one.txt
git add ./
git cm "add one.txt"
git co master
git merge my-feature-x
git push
# [on conflict]
git pull
<resolve>
git push

И ветка у тебя только локально. И в приницпе co -b можно сделать всегда. Ну и так далее. И есть ещё git pull --rebase ну и так далее.

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

Ну так это ты хочешь всё усложнить. Вообще-то никто так не делает

Конечно не делает — на stackoverflow и в туториалах советуют придерживаться схемы с чистой репой и единственным сценарием коммитов; шаг в сторону — расстрел. Ну, то есть не расстрел, а «любись как хочешь — твои проблемы». Большинство даже не рискуют в итоге сходить с проторенной дорожки. В итоге, спустя время они привыкают и даже не задумываются над тем, что им на самом деле неудобно.

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

Вот мои:

br = branch
co = checkout
st = status -sb
l = log --graph --pretty=format:'%Cred%h%Creset %C(bold blue)<%an>%Creset%C(yellow)%d%Creset %s %Cgreen(%cr)' --abbrev-commit --date=relative 

P.S. Где как не в теме про Go это спросить? :)

Всего N лет назад разные проекты использовании разные VCS, у одно это bazzar, другого svn, у третьего mercular, разве от этого было проще? Надо было знать CLI всех этих тулов, хотяб чтоб скачать исходники, найти изменения в истории, понять концепцию используемого бранчинга в конкретном VCS чтоб знать где искать

К абсолютно любому из упомянутых инструментов привыкаешь очень быстро. У меня вообще никогда не возникало реакции «блин, тут свн используется. Как же я теперь с ним буду работать?». И только Git удалось создать реакцию «ЧТО ЭТО? ЧТО МНЕ ВООБЩЕ С ЭТИМ ДЕЛАТЬ?». Еще раз повторюсь: эта реакция коррелирует с опросом 4000 пользователей Git в 2014, которые тоже в большинстве считали, что интерфейс и доки у Git плохие.

Мне кажется, что ты забыл свои собственные слова:

И для «сложных» смертных, которым нужны ещё и merge, rebase и чери-пик (особенно).

Если ты работаешь один или кто-то редко пушит в твой репо, то тебе хватит и pull/commit/push.

Если людей много, то ещё и ветки.

Если конфликты при работе – это сложный случай и нужно мержить ултилитой или как-то.

Те сложности о которых говришь ты (бисект и встроенный веб-сервер) – не нужны никому. Ну бисект нужен, если ты ищешь дыру в чём-то большом. Тут скорее лучше разбить на на подмодули. Получается, что бисект нужен только для неразделяемых монсторов типа ядра Linux. Хотя и это вопрос. Никто не хочет париться с разделением – оттого и бисект. Для ядра может бисект и проще. А вообще, это звоночек.

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

А ещё git имеет экспорт из некоторых (?) других VCS, что сильно упрощает миграцию на него.

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

И только Git удалось создать реакцию «ЧТО ЭТО? ЧТО МНЕ ВООБЩЕ С ЭТИМ ДЕЛАТЬ?»

Этим людям наверное забыли провести инструктаж на работе

Но я не хочу вносить эти локальные правки из Makefile в общую репу

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

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

Так я профессионально копипащу их с интернета по запросу в гугле git aliases (напр.: https://githowto.com/ru/aliases).

P.S. Где как не в теме про Go это спросить? :)

InstadOf для Go =)

[core]
	editor = nano
[alias]
	co = checkout
	ci = commit
	st = status
	br = branch
	hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
	type = cat-file -t
	dump = cat-file -p
	cm = commit -a -m
	ignore = update-index --skip-worktree
	unignore = update-index --no-skip-worktree
	ignored = !git ls-files -v | grep \"^S\"

[url "ssh://git@github.com/"]
    insteadOf = https://github.com/

Надо бы для стэша что-то придумать…

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

«Вот, ты правильно хихихикаешь»

Это не наш инструмент — негибкое говно, а мы неправильно организуем наш проект. Давайте лучше покрошим цельный функционал на мелкие-мелкие файлы по 20-50-100 строк, да еще и раскидаем их по разным папкам, чтобы с большой вероятностью не было конфликтов. Я лично был свидетелем такого. И что вы думаете? Конфликты все равно были. Я добавил одну строчку в файл на 5 строчек, а кто-то добавил другую строчку в этот же файл, и вуаля — конфликт правок в файле на 5-6 строк. В одном из тысячи файлов из проекта на 50 тысяч строк.

А решалось всё просто — выкидыванием Git на помойку и применением любого другого удобного решения.

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

Это да. Потому что доки довольно обширны. Краткая вводная была бы проще. Я лично осваивал по главе из Railstutorial.

Если ты работаешь один или кто-то редко пушит в твой репо, то тебе хватит и pull/commit/push

Мне хватало «tar -cvf». О чем и начинался разговор.

А ещё git имеет экспорт из некоторых (?) других VCS, что сильно упрощает миграцию на него

Mercurial поддерживает даже подпроекты на SVN и Git.

Я добавил одну строчку в файл на 5 строчек, а кто-то добавил другую строчку в этот же файл, и вуаля — конфликт правок в файле на 5-6 строк.

Ну и? Ты просто пушишь и всё сливается. Если есть конфликты, то их нужно разрешать. И если какой-то инструмент их решает сам, значит и git это может. В других же случаях – решать всё равно приходится вручную. И VCS тут никак не поможет. Если ты коммитишь 5, а Васян 3 на то же место, то что по твоему должна делать VCS? Затереть? Ну так пушь фаст-форвардом, но это вообще не тот путь. Сама разрешить? Как, чёрт побери? Тебе Git даже функцию перехавшую в другой файл показывает – откуда она и всё про неё. Чего тебе ещё не хавтает?

Мне хватало «tar -cvf». О чем и начинался разговор.

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

Спасибо!

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

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

Этим людям наверное забыли провести инструктаж на работе

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

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

Изменения из stash не пропадают после drop/pop/clear, то есть, в этом плане подобны коммитам, потому механизм хранения локальных правок в stash на самом деле весьма близок к хранению их же локально в коммитах на ветке с последующим rebase+squash.

SVN до сих пор достойный варик для централизованной разработки

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

Еще помню что люди могли несколько дней (и даже неделю) работать над кодом не комитя изменения пока все не завершат. Сейчас это кажется стремным.

Я добавил одну строчку в файл на 5 строчек, а кто-то добавил другую строчку в этот же файл, и вуаля — конфликт правок в файле на 5-6 строк.

Ну и? Ты просто пушишь и всё сливается

Неа, не сливается. Пруф:

$ echo "more 1" >> Makefile

$ git commit -a -m "more 1"
[master 26808c5] more 1
 1 file changed, 1 insertion(+)

$ cd ../test2
$ echo "more 2" >> Makefile
$ git commit -a -m "more 2"
[master f1a4c05] more 2
 1 file changed, 1 insertion(+)

$ git pull ../test
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ../test
 * branch            HEAD       -> FETCH_HEAD
Auto-merging Makefile
CONFLICT (content): Merge conflict in Makefile
Automatic merge failed; fix conflicts and then commit the result.

И это довольно частая ситуация: я добавил, ты добавил, наши правки независимы, но — упс, Git не может это слить автоматически.

Мне хватало «tar -cvf». О чем и начинался разговор.

«Я хочу чтобы в мою поделку никто другой не пушил», это называется

Кинь мне патч - я добавлю и выдам тарбол. Это не так уж и сложно. И это — нулевая точка отсчета, полностью ручное управление ревизиями. VCS должно давать какие-то преимущества относительно этого нуля, чтобы ее применение стало обоснованным.

tar -cvf это годный VCS, первый год освоения git я без него ни одной команды в git не делал :)

Изменения из stash не пропадают после drop/pop/clear

Только после drop или clear их придется искать с собаками

механизм хранения локальных правок в stash на самом деле весьма близок к хранению их же локально в коммитах на ветке с последующим rebase+squash.

да, но возни больше

Проводить месячный курс по пользованию Git?

Я своим одну лекцию прочитал, и все все поняли. Если что-то непонятно, у меня спрашивают. Ни разу не видел, чтобы кто-то делал такую дичь как архивные копии репы, reflog смотреть умеют

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

Да, ветки как бы являются отдельными папками в SVN. Патч можно достать без скачивания всех сорцов через svn diff, применяется через svn patch с отслеживанием созданий и удалений (но не перемещений), а «git rebase» по сути то же самое делает. В Mercurial аналогичная задача решается при помощи «hg diff; hg import», либо расширением «Rebase».

Еще помню что люди могли несколько дней (и даже неделю) работать над кодом не комитя изменения пока все не завершат. Сейчас это кажется стремным

Стрёмно, если нет резервного копирования. Я еще раз хочу напомнить, что у меня два жестких диска умерло, но я почти ничего не потерял.

Нубы ворчат, а меж тем Git уже дефакто давно стандарт отрасли.

Изменения из stash не пропадают после drop/pop/clear

Только после drop или clear их придется искать с собаками

gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )

Потом поиск по «index on». На моей 2.21 прокатывает.

механизм хранения локальных правок в stash на самом деле весьма близок к хранению их же локально в коммитах на ветке с последующим rebase+squash.

да, но возни больше

Ты хочешь сказать, что «git rebase -i» проще работает, что ли? Если конфликтов нету, то патчи для SVN отработают быстро и тихо.

Стрёмно, если нет резервного копирования.

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

Git и подход принятый в команде может решить эту проблему. Например заставить пушить код в свои бранчи в конце рабочего дня, благо для этого ненужно решать конфликты, всего две команды git commit -m "EOD" и git push

gitk –all $( git fsck –no-reflog | awk ‘/dangling commit/ {print $3}’ )

Ну вот это я и имел в виду «искать с собаками». С веткой все в сто раз проще, так как есть рефлог и ее можно забэкапить

Ты хочешь сказать, что «git rebase -i» проще работает, что ли?

Если у тебя есть несколько локальных патчей, которые ты применяешь к «апстримной» ветке, то тебе не нужен -i, ты просто делаешь rebase (или даже pull –rebase, если лень создавать отдельную ветку)

Я своим одну лекцию прочитал, и все все поняли

Что «всё»? Я думаю, что тебе не нужно объяснять, насколько глубока эта кроличья нора. Мне вот вообще никто ничего не объяснял, но я сам обучился через гугль, stackoverflow, в меньшей степени через официальные доки. Насколько этот канал был востребован у твоих коллег?

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

Я поучаствовал в одном опенсорсном проекте и мне там быстро вправили мозги и отучили делать дичь.

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

Ну вот это я и имел в виду «искать с собаками». С веткой все в сто раз проще, так как есть рефлог и ее можно забэкапить

Что в сто раз проще? Ты сделал rebase, не оставив ссылки на оригинальную ветку — и привет, «gitk –all $( git fsck –no-reflog | awk ‘/dangling commit/ {print $3}’ )».

Стэши при этом тоже прекрасно складируются, по сути выполняя тот же rebase во время «stash pop» или «stash apply».

Если у тебя есть несколько локальных патчей, которые ты применяешь к «апстримной» ветке, то тебе не нужен -i, ты просто делаешь rebase (или даже pull –rebase, если лень создавать отдельную ветку)

"-i" нужен для последующего сплющивания истории.

Вот эта штука в свое время мне помогла: https://vtk.org/Wiki/Git/Workflow/Topic.

Если понять, что гит - это просто граф из коммитов, у некоторых могут есть «символические имена» (бранчи, теги), и как этот граф меняется ребейзами и мержами, то все становится практически очевидно. Можно уже самому осознанно выбирать воркфлоу для любой ситуации.

Ты сделал rebase, не оставив ссылки на оригинальную ветку

Открыл reflog, зачекаутил предыдущий вариант ветки. Чтд.

Я поучаствовал в одном опенсорсном проекте и мне там быстро вправили мозги и отучили делать дичь

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

«-i» нужен для последующего сплющивания истории.

Если у тебя один «временный» коммит, то проще прямо в него коммитить из git gui