Mercurial против Git в Facebook

git делает то что ты ему сказал

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

Если твоя среда разработки падает от невалидного синтаксиса – твоя среда разработки бесполезна

ну скорее наоборот, если она не реагирует на изменение исходников то вас обманули и это редактор текстов, а не «студия»

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

Говорил-говорил. git merge это подразумевает, как и любая другая популярная vcs. Не прикидывайся шлангом.

ну скорее наоборот, если она не реагирует на изменение исходников то вас обманули и это редактор текстов, а не «студия»

Если она от этого падает и её нужно перезапускать – она говно, а не студия. Все LSP серверы что я видел умеют справляться с кривыми синтаксисом.

git merge это подразумевает

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

Если она от этого падает и её нужно перезапускать

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

Но мне кажется если бы разработчики гита думали головой

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

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

что у большинства всё нормально

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

большинство работает с кодом менее эффективно

Менее эффективно чем кто? Чем ты? Но ведь если у них не разваливается ничего, то менее эффективно работаешь как раз ты.

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

А причём тут git?

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

Здраствуйте. Я, Syncro. Хотел бы чтобы вы сделали утилиту, систему контроля версий суть такова… Пользователь может играть разроботчеком, билд-сервером и веткой. И если пользователь играет разроботчиками то исходники в сервере, конфликты набигают говнокод и сборочный сервер. Можно грабить корованы… И розроботчики раз прогроммируют то сделать так что там многа веток…

Менее эффективно чем кто? Чем ты? Но ведь если у них не разваливается ничего

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

Менее эффективно чем кто? Чем ты? Но ведь если у них не разваливается ничего

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

Меня пугает, что это всё одно предложение, и, честно говоря, я не собираюсь даже пытаться осознать эту шизофазию.

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

Стойкое ощущение, что в коде у вас помойка. Но очень профессиональная.

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

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

Твое представление о том, как работает merge в актуальных VCS не соответствует действительности. Ты можешь продолжать упорно отрицать реальность, но она никуда не денется.

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

Я правильно понимаю, что если ты вышел посрать посреди написания кода, происходит то же самое? Зачем такое нужно?

Если появление в коде символов ASCII приводит к падению твоей DE, то выбрось свою студию.

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

то выбрось свою студию.

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

использование гита приводит к падению всего, и его надо выбросить,

Ну, выброси. Кто ж тебе запрещает-то? Я лет 10 назад слышал про контору, где никакого git не было. Даже SVN не было! Каждый вечер все программисты паковали результаты своей работы и по email посылали главному программисту, а тут руками складывал изменения воедино. Тебе такой режим наверняка подойдёт.

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

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

С Брежневым можно согласиться в том. что git не хватает транзакционности. То есть каждая операция должна из одного корректного состояния переводить в другое, а конфликты всё же обозначать как-то по другому.

С Брежневым можно согласиться в том. что git не хватает транзакционности. То есть каждая операция должна из одного корректного состояния переводить в другое, а конфликты всё же обозначать как-то по другому.

А зачем?

если ты отойдешь от клавиатуры, не дописав строчку кода

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

С Брежневым можно согласиться в том. что git не хватает транзакционности. То есть каждая операция должна из одного корректного состояния переводить в другое, а конфликты всё же обозначать как-то по другому.

Не, соглашаться с ним нельзя. Он поехавший.

Но если тебе так не нравятся >>> и <<<, то можно их просто… не коммитить! Можно ещё добавить хук, который будет отфутболивать такие коммиты, но это для искушённых.

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

А это не важно. Если я опечатался и получил дорогостоящее по времени падение какого-то процесса, значит этот процесс – говно.

Если я правильно понял происходящую шизофрению, «<<<<» вызывают падение условного LSP сервера на его локальной машине.

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

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

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

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

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

Она их показывает. Но она при этом не падает :)))))

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

То есть если я руками добавлю === >>> <<<, то тожеигит будет виноват?

зачем добавите?

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

#!/usr/bin/env bash

# Check for merge conflicts

# Tested on Linux and Mac

# Simple check for merge conflics
conflicts=`git diff --cached --name-only -G"<<<<<|=====|>>>>>"`


# Something went wrong
if [[ -n "$conflicts" ]]; then
    echo
    echo "Unresolved merge conflicts in these files:"

    for conflict in $conflicts; do
        echo $conflict
    done;

    exit 1;
fi

exit 0

Держи. Добавь этот хук к себе на сервер, оно перестанет падать.

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

Я не понимаю происходящую у тебя шизу. Как делают нормальные люди:

1. Пишут код (IDE)
2. Пушат на сервер

К пункту (2) код валиден и никаких проблем нет. Я не знаю что там творится у тебя, но то что творится не имеет к адекватности никакого отношения.

Начну вводить значение строковой константы, не с кавычек. Нельзя разве?

если автосохранение повешано на потерю фокуса этим вы ничего не сломаете

если автосохранение повешано на потерю фокуса этим вы ничего не сломаете

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

К пункту (2) код валиден и никаких проблем нет.

если между 1 и 2 кто-то успел запушить то это может быть не так, кроме того, вы пушите в свою ветку, а ее еще надо будет сливать

если между 1 и 2 кто-то успел запушить то это может быть не так

Чот запушит? Пока ты находишься в режиме мержа, ты не можешь пушить промежуточное состояние.

а потом случайно мышку передвинет, то билд-серверу крышка и вообще вся контора встанет раком?

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

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

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

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

Нет, это не помойка, просто сильная связность (которая cohesion). Например, характерны зависимости protobuf’ов между кучей проектов, и это вообще ни разу не антипаттерн.

Congratulations! You’ve been promoted to Customer.

У нас в монорепе циклические зависимости запрещены системой сборки.

Да, есть такое. «Это что же вместо svn checkout запускать git clone? Вместо svn update - git pull? Ни за что!»

И вместо понятного номера версии, растущего монотонно в svn, иметь какой-то непроизносимый набор цифр?

:)

И вместо понятного номера версии, растущего монотонно в svn, иметь какой-то непроизносимый набор цифр?

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

Экстремисты, что с них взять.

Это не нужно. Лучше понятный номер сборки, а его можно обеспечить средствами CI.

Ну в mercurial они растут монотонно, но только пока есть только одна ветка: как только появляется вторая, то, например, в ветке default появляется разрыв в нумерации. Так что толку от этого немного.

Аналогично в svn - номер ревизии может быть бесполезен, если не знаешь в какой ветке смотреть, а в trunk такой ревизии нет.

Прекрати демагогию.

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

А в релизную надо мержить уже готовое одним коммитом, как ты любишь

Ты хотел коммит, соответствующий осмысленной релизной правке - вот я тебе написал как они делаются. И он при этом вполне независимый и атомарный. Что за «сквош» я не знаю.

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

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

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

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

Если продолжить твою логику, то хостить коммиты вообще не нужно

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

Это нужно и самому разработчику: можно через год будет вспомнить, зачем он внёс в код какую-то мелочь

Причёсанная ветка нужна. Только её не надо никак хранить - она попадает в виде такого же набора коммитов в транк. Помойковетка не нужна ни в каком виде.

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

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

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

Напротив, руководству интересен только результат. Если времени на задачу «добавление кнопки» портачен месяц, то совершенно наплевать что от там делал месяц - в потолок плевал, или в поте лица перебирал css атрибуты которых не знает и правил ошибки линтера. Результат один - кнопка за месяц. А если он там реально занимался нужным рефакторингом, то в результате будут коммиты связанные с рефакторингом. Больше ничего не нужно.

include без peerdir никто не запрещал и не запретит.