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

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 разные вещи делают.

Про GC в Go подробно: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd8e

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

А если приложуха на Го занимает 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ись, а вместо этого ты ему тыкаешь всякими языками программирования и прочим мусором» :)

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

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

а тут ругают git

а тут ругают git

Не использую git, … - non problem.

Владимир

Не использую git, … - non problem.

Не приходилось производить разработку в группе программистов.

"Понимаете как в таких условиях легко работается?"

Владимир

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

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

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

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

Ничего не пишут,  а это - минус.  
Но и   не ругают, а это - плюс.

Владимир

Не использую git, … - non problem.

Вань, 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?

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

ты просто не можешь в общем случае передать результат os.Readdir() в os.Open().

Внутреннее представление string в Go — это []byte. Как это может мне помешать передать результат?

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

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

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

Владимир

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

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

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

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

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

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

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

Владимир

а можно вывести и предварительно проверив

Давайте тогда вообще все данные хранить в int-ах? Ведь можно предварительно проверить.

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

Конечно нет.

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

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

Владимир