V>Пример, ты работаешь на фичей и я, допустим ты уже сделал кусок, который нужен мне, но он у тебя разбросан по 100500 комитам, типа wip1 wip2 wip3 (очень полезно) V>Если бы делал нормально, то можно было бы просто вырезать нужный комит и сделать пулл реквест, или просто зачерипикать.
Ты писал про не плодить промежуточных и мелких
V> Только разница в том, что в истории не будет шума о том как я переименовывал класс 5 раз, пока не определился с именем.
Ну, настолько мелких мы не делаем Не все так запущено как ты нарисовал в своем воображении.
Здравствуйте, vovkab, Вы писали:
V>Вы суете кучу мусора в историю, от этого и появилась надобность выслеживать по ветка, иначе похоже вообще ни как. V>Я даже не представляю как вы git blame используете с такой историей, наверное вообще жесть?
Слегка утрировано конечно написал. Нормально все с blame. Просто без фанатизма отношусь к требованиям по оформлению коммитов. VCS это врежде всего фиксация потока идей и состояний. Вовсе не обязательно чтобы каждый коммит можно было зачекаутить и получить нормально работающее приложение. Вот в конце ветки да, обязательно.
V>Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно.
Это не косяки, с чего ты взял-то. Важен момент мержа ветки, а не ее внутренние состояния. В околоисследовательских и научных проектах одно из этих состояний может вдруг резко понадобиться чтобы обкатать отброшенную ранее идейку на новых входных данных.
V>С какого перепугу что то поломается? V>Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается? V>Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
Ну ты почитай почему в dcvs считается табу history rewriting удаленного репозитория с которым синкаются другие. И зачем придумали команду revert
Здравствуйте, Cyberax, Вы писали:
C>Это извращение, а не фантастика. Примерно на том же уровне, что и "checkout" файлов из SourceSafe.
Чушь несешь.
Не знаю как ты, а я живу в 21 веке и ревью делаю с помощью более удобных тулзов чем веб-просмотрщик текста. Про сорсейф не в курсе че ты там думаешь
Здравствуйте, willie, Вы писали:
W>>>Весь этот тред сводится к спору пары человек которые видимо работают в распределенных командах. W>·>Даже в централизованной команде можно распределяться между собой — офисный десктоп/домашний десктоп/лаптоп/виртуалки. W>Это и без гита можно.
Можно, конечно. Но гит предоставляет удобные фичи для этого.
W>>>Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз W>·>Какие косяки приходится разруливать? Тем более в случае вашей централизованной разработки. W>Я ж написал. Прямо в предложении на которое ты отвечаешь.
Ты написал из-за чего косяки, а не какие косяки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>>>Я вижу как минимум проблему найти удобно коммиты которые ревертить. W>·>Это никак не зависит от наличия/отсутствия перманентных бранчей. W>Бранчи удобнее.
Дело привычки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй. W>И потом не сможешь создать второй такой же.
Я смогу. А тебе что мешает?
W>>>Это тебе не меркуриал с его мегафичей вечных веток. W>·>Это не мегафича, а тяжелое наследние cvcs. W>Не вижу ничего тяжелого, одни плюсы.
Бессмысленная сложность с эфемерной выгодой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно.
W>Это не косяки, с чего ты взял-то. Важен момент мержа ветки, а не ее внутренние состояния. В околоисследовательских и научных проектах одно из этих состояний может вдруг резко понадобиться чтобы обкатать отброшенную ранее идейку на новых входных данных.
Изменение должно иметь смысл и фиксироваться комитом. Если ты изменил одно и тоже несколько раз в течении локальной истории, значит это должно быть объединено.
V>>С какого перепугу что то поломается? V>>Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается? V>>Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
W>Ну ты почитай почему в dcvs считается табу history rewriting удаленного репозитория с которым синкаются другие. И зачем придумали команду revert
Не путай локальную работу и комиты в паблике.
Пока ты в своей песочнице можешь делать что хочешь.
Здравствуйте, willie, Вы писали:
C>>Это извращение, а не фантастика. Примерно на том же уровне, что и "checkout" файлов из SourceSafe. W>Чушь несешь. W>Не знаю как ты, а я живу в 21 веке и ревью делаю с помощью более удобных тулзов чем веб-просмотрщик текста.
А оно работает с моим vim? Или обязательно в Ein Volk, ein Reich, ein Füh Визуальной Студии?
Здравствуйте, ·, Вы писали:
_>>Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? ) ·>commit -i заставляет сделать всё одной командой — выбирать сразу. серия команд "add", "add -p" упрощает жизнь. ·>Например, IDEA не поддерживает (интересно, а какие поддерживают?) интерактивный коммит, может добавлять только файлы. У меня есть возможность добавить какие-то файлы из UI, а какие-то по-hunk-ово из командной строки.
Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. )))
_>>·>Все push можно сделать одной командой. Тогда и получится столько же или даже меньше. _>>·>Например можно сделать так так: _>>·>... _>>·>В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution. _>>Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.) ·>Что значит ересь? Граф истории — идентичен. Только имена веток отличаться будут.
Ну да, только вот как отличаться... У тебя там во 2-ом репозитории при варианте "Б" будет в master храниться ревизия "А" (кстати, долго она там будет храниться? При следующем git pull то туда затянутся изменения из удалённого master или alternativeUnmergedSolution?), в changeB будет содержимое аналогичное master в удалённом. Короче бред и подобную ересь по любому пришлось бы потом ещё править. )
Здравствуйте, alex_public, Вы писали:
_>>>Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? ) _>·>commit -i заставляет сделать всё одной командой — выбирать сразу. серия команд "add", "add -p" упрощает жизнь. _>·>Например, IDEA не поддерживает (интересно, а какие поддерживают?) интерактивный коммит, может добавлять только файлы. У меня есть возможность добавить какие-то файлы из UI, а какие-то по-hunk-ово из командной строки. _>Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. )))
Какой gui? Встроенный в IDE? Или отдельный?
_>>>Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.) _>·>Что значит ересь? Граф истории — идентичен. Только имена веток отличаться будут. _>Ну да, только вот как отличаться... У тебя там во 2-ом репозитории при варианте "Б" будет в master храниться ревизия "А" (кстати, долго она там будет храниться? При следующем git pull то туда затянутся изменения из удалённого master или alternativeUnmergedSolution?), в changeB будет содержимое аналогичное master в удалённом. Короче бред и подобную ересь по любому пришлось бы потом ещё править. )
Если будешь на master возвращаться, зарезеть его в начальный:
git checkout -B master origin/master
Всяко лучше чем голые номера ревизий безымянных голов использовать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. ))) ·>Какой gui? Встроенный в IDE? Или отдельный?
Смотря для каких действий. Скажем ветками порулить, синхронизироваться и т.п. я как-то привык из внешнего инструмента (TortoiseHg). А скажем посмотреть историю файла и т.п. вопросы связанные уже с контентом обычно из IDE делаются.
Здравствуйте, alex_public, Вы писали:
_>>>Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. ))) _>·>Какой gui? Встроенный в IDE? Или отдельный?
_>Смотря для каких действий. Скажем ветками порулить, синхронизироваться и т.п. я как-то привык из внешнего инструмента (TortoiseHg). А скажем посмотреть историю файла и т.п. вопросы связанные уже с контентом обычно из IDE делаются.
Ну собственно вот... Плюс иногда требуется command line, для каких-то более сложных действий, например, какой-то хитрый скриптик можно написать.
Одного UI не всегда достаточно, приходится разные использовать. И staging в этом помогает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
V>>Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно. W>Это не косяки, с чего ты взял-то. Важен момент мержа ветки, а не ее внутренние состояния. В околоисследовательских и научных проектах одно из этих состояний может вдруг резко понадобиться чтобы обкатать отброшенную ранее идейку на новых входных данных.
Люди косячат. Если в результате peer review приходит замечание "ты ещё в паре мест забыл логику подправить", это достаточное основание модифицировать ранее предложенный коммит.
На исследовательскую идею состояние "исправил три места, про ещё два забыл" не тянет даже после ста грамм.
V>>С какого перепугу что то поломается? V>>Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается? V>>Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
W>Ну ты почитай почему в dcvs считается табу history rewriting удаленного репозитория с которым синкаются другие. И зачем придумали команду revert
При всём при этом ветки промежуточной подачи правок в Linux проходят такую переписку почти ежедневно, а в git help rebase есть глава, как работать, если в апстриме такое происходит.
Это, конечно, далеко не для рядового исполнителя. Но и показывает, что "табу" не существует, а вместо этого есть разумная экономия усилий для типичного случая.
Здравствуйте, willie, Вы писали:
N>>IDE не рассматриваем тут принципиально. W>А по-моему наоборот, dcvs без нормальной интеграции с IDE это меньше чем половина dcvs. W>Ковыряться в консоли в 99% случаев нафиг не упало.
Я не рассматривал IDE потому, что говорил о базовых тулзах, а не о том, как они сынтегрированы с конкретной версией конкретной IDE (не имея, например, опыта с VS больше двухстраничных поделок, я не хочу про неё говорить вообще).
W>У тебя просто юскейсы специфичные. Мне вот interactive-add ни разу не нужен был Даже без понятия был что это такое пока твое сообщение не прочитал.
Специфичные юзкейсы у всех, а начинают так говорить, когда не понимают обстановку собеседника.
Тем не менее, да, у меня требование аккуратного расщепления коммитов по сущности изменения и возможностью каких-то локальных правок дольше, чем на коммит, является обязательным для возможности адекватного сопровождения (и никак не связано с opensource, как тут ещё выдвигалось).
Здравствуйте, alex_public, Вы писали:
N>>А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них N>>* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение N>>* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать N>>* функциональное изменение по возможности максимально однородно по сути действий N>>и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.
_>Это похоже на какие-то опенсорсные заморочки. )))
Это базовая гигиена работы над действительно большим проектом, и мне крайне странно слышать подобные замечания в принципе. С open source это никак не связано, скорее наоборот — пока последний находился в основном в зачаточном состоянии, эти требования уже формулировались для промышленного программирования; и те проекты, на которых в моём случае это выдвигалось, не предполагались ни для какого публичного открытия.
N>>И реально сложное изменение такого рода не сделать без возможности разделения, перестановки, слияния коммитов, выбора нужного из локальных изменений. А если какое-то современное средство прячет эту функциональность поглубже (отдельные команды, выключенные по умолчанию расширения), то его авторы целенаправленно воспитывают ламеров и говнокодеров.
_>У меня противоположное мнение. )
Это я уже понял, и на это могу только предположить, что у тебя нет проектов, которые длятся более 10 лет с неоднократной сменой команды исполнителей, при одновременной работе 20-30 человек.
Если же такие есть, я могу только посочувствовать тем проблемам, которые они разгребают за предыдущими коллегами и которые создают на свои же головы и задницы на чуть позже.
_>Собственно hg record был в старых версиях Mercruial, а в новых просто hg commit -i. Так что всё становится до конца логично и понятно, и без всяких расширений.
Но в документации так и остаётся бред.
_>Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики.
Если это тупик, полученный в результате конструктивного и ответственного применения того, что было известно до того — да, он должен быть документирован. Но не в коде (скорее всего, он должен остаться в немерженной ветке), а в сопроводительной документации и в историческом отчёте. Типа "для выбора варианта реализации структуры было измерено 4 версии (описание версий), тикет на измерение #143502, код и результаты измерений сложены в репо BigProject.aux".
Если же это, как в >90% случаев, недоработка вида "а тут не учтён ещё один случай", "изменено 3 места применения, а ещё про 2 тупо забыто" и ловится коллегами на peer review — никакой причины "документировать" это где-то кроме поточных отчётов о проделанной работе — нет, и тем более — вечно сохранять эти ляпы и тестовые версии в коде. Там и без того будет достаточно случаев недоработки и кривой оценки.
Твои лично-оценочные выпады типа "забыл", "вообще не знал" лучше спрятать подальше, раз ты не отличаешь действительно инженерные проблемы от проблем рабочего процесса.
N>>>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией. _>>>А как можно организовать цепочки без фиксации? ) N>>Ключевое слово было "безымянных". Не делай вид, что не понял этого. _>Ну так в Git же цепочки тоже внутри безымянные (у них есть только хэш, как и в Mercurial), а имена вешаются поверх (как закладки в Mercurial).
Сохраняются те, которым даны постоянные ссылки. И, как я уже кучу раз говорил, это правильно.
Я был бы не против видеть безымянные головы как расширение не только в Hg, но в любой системе, но только выключенным по умолчанию, и включаемым под личную ответственность пользователя.
Здравствуйте, willie, Вы писали:
V>>Не совсем понятно зачем, но да ладно. V>>При мерже обычно создается мерж комит в котором есть информаци какая ветка куда была замержена. W>Там нет информации что входило в эти ветки.
Есть id всех предковых коммитов, порядок id соответствует направлению мержа.
W>Да и сам ответ жесть какая-то. Такая куча буков и мешанина команд чтобы просто найти что Вася пилил в своей ветке месяц назад.
Не все так запущено как ты нарисовал в своем воображении.
