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

_>>Это похоже на какие-то опенсорсные заморочки. )))
N>Это базовая гигиена работы над действительно большим проектом, и мне крайне странно слышать подобные замечания в принципе. С open source это никак не связано, скорее наоборот — пока последний находился в основном в зачаточном состоянии, эти требования уже формулировались для промышленного программирования; и те проекты, на которых в моём случае это выдвигалось, не предполагались ни для какого публичного открытия.

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

_>>У меня противоположное мнение. )
N>Это я уже понял, и на это могу только предположить, что у тебя нет проектов, которые длятся более 10 лет с неоднократной сменой команды исполнителей, при одновременной работе 20-30 человек.
N>Если же такие есть, я могу только посочувствовать тем проблемам, которые они разгребают за предыдущими коллегами и которые создают на свои же головы и задницы на чуть позже.

И чем же более подробная (а не приглаженная искусственно) история способна помешать долговременной работе над проектом? )

_>>Собственно hg record был в старых версиях Mercruial, а в новых просто hg commit -i. Так что всё становится до конца логично и понятно, и без всяких расширений.
N>Но в документации так и остаётся бред.

В документации указаны оба варианта (потому что не у всех стоит обязательно последняя версия Mercurial). В документации и такие https://www.mercurial-scm.org/wiki/BookmarksExtension вещи можно до сих пор увидеть, хотя они давно не актуальны (и это там тоже указано).

_>>Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики.
N>Если это тупик, полученный в результате конструктивного и ответственного применения того, что было известно до того — да, он должен быть документирован. Но не в коде (скорее всего, он должен остаться в немерженной ветке), а в сопроводительной документации и в историческом отчёте. Типа "для выбора варианта реализации структуры было измерено 4 версии (описание версий), тикет на измерение #143502, код и результаты измерений сложены в репо BigProject.aux".

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

N>Если же это, как в >90% случаев, недоработка вида "а тут не учтён ещё один случай", "изменено 3 места применения, а ещё про 2 тупо забыто" и ловится коллегами на peer review — никакой причины "документировать" это где-то кроме поточных отчётов о проделанной работе — нет, и тем более — вечно сохранять эти ляпы и тестовые версии в коде. Там и без того будет достаточно случаев недоработки и кривой оценки.

А это тоже полезно сохранять, но уже для других целей. Так сказать административно-кадровых. )))

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

S>>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.

K>Вот потому он и не нужен™

Неправда это всё. Обычно в команде гитом по настоящему умеет пользоваться 1-2 человека, и проблем не возникает, всё работает.

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

S>>После работы с такими коммерческими тулами как ClearCase, Synergy, Rational TeamConcert мне Git показался самым разумным что было изобретено в этой области. Особенно в плане написания интеграций с ним.

V>Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет.

git хорош, гитхабом не пользуюсь.

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


C>А оно работает с моим vim? Или обязательно в Ein Volk, ein Reich, ein Füh Визуальной Студии?

"оно" писалось для студии и работает в студии. Аналоги думаю можно найти для всех нормальных ide.
Есть ли аналоги для твоего вим не знаю. Вимом пользуюсь только для commit -m

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


N>Есть id всех предковых коммитов, порядок id соответствует направлению мержа.
Знаю. Есть. Круто.
Я что ли ручками это смотреть должен?
Какая-то удобная тулза есть? В tortoise git я не нашел. Есть упоротый граф веток, который без пузыря хрен разберешь.

Здравствуйте, netch80, Вы писали:
N>Люди косячат. Если в результате peer review приходит замечание "ты ещё в паре мест забыл логику подправить", это достаточное основание модифицировать ранее предложенный коммит.
N>На исследовательскую идею состояние "исправил три места, про ещё два забыл" не тянет даже после ста грамм.

Ты только что напесал отсебятину полную. Нету у нас такого.
Ну или ты не так понял что я написал.

N>При всём при этом ветки промежуточной подачи правок в Linux проходят такую переписку почти ежедневно, а в git help rebase есть глава, как работать, если в апстриме такое происходит.

Т.е. они сами не соблюдают свои рекомендации. Быдлоразроботка, ясно-понятно

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


V>Изменение должно иметь смысл и фиксироваться комитом.
Да

V>Если ты изменил одно и тоже несколько раз в течении локальной истории, значит это должно быть объединено.

Нет.

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

W>>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй.
W>>И потом не сможешь создать второй такой же.
·>Я смогу. А тебе что мешает?

Создать несколько локальных веток с идентичными именами?

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

W>>Бранчи удобнее.
·>Дело привычки.

Ну ок.
Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно.
Консоль не предлагать.

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

W>>>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй.
W>>>И потом не сможешь создать второй такой же.
W>·>Я смогу. А тебе что мешает?
W>Создать несколько локальных веток с идентичными именами?
Да, их можно в разных префиксах (namespaces) разместить. Полное имя будет разным, конечно, но ты пока не объяснил необходимость неразличимых имён. "Сделать так как умеет hg" я как объяснение не приму. Ибо даже в оф доках так не рекомендуют делать.

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

W>>>Бранчи удобнее.
W>·>Дело привычки.

W>Ну ок.
W>Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно.
W>Консоль не предлагать.
Путаешь цель и средство. Цель-то какая преследуется?

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

w> W>>Бранчи удобнее.

w> ·>Дело привычки.

w> Ну ок.
w> Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно.
w> Консоль не предлагать.

"Хочу забить гвоздь. Молотки не предлагать"
Имея сообщения в логе типа wip, wip, commit, fix (как у вас принято в команде судя по прошлым сообщениям) без веток конечно сложновато понять что к чему
Ближе к сути вопроса: что заставляет удалять ветки?

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

·> W>>>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй.

·> W>>>И потом не сможешь создать второй такой же.

·> W>·>Я смогу. А тебе что мешает?

·> W>Создать несколько локальных веток с идентичными именами?

·> Да, их можно в разных префиксах (namespaces) разместить. Полное имя будет разным, конечно, но ты пока не объяснил необходимость неразличимых имён. "Сделать так как умеет hg" я как объяснение не приму. Ибо даже в оф доках так не рекомендуют делать.
С одинаковыми именами у меня вопрос: 2 дева работали над разными проблемами с базой данных и назвали свои ветки db_fix. Что получим на выходе? Как определить какая именно проблема решалась в какой ветке?

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

·> W>>>Бранчи удобнее.

·> W>·>Дело привычки.

·> W>Ну ок.
·> W>Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно.
·> W>Консоль не предлагать.

·> Путаешь цель и средство. Цель-то какая преследуется?
Это распространенная проблема судя по форумам задать вопрос типа "Как улучшить у микроскопа сопротивляемость ударным нагрузкам?" в то время как правильный вопрос "Как забить гвоздь?"

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

_>>>Это похоже на какие-то опенсорсные заморочки. )))
N>>Это базовая гигиена работы над действительно большим проектом, и мне крайне странно слышать подобные замечания в принципе. С open source это никак не связано, скорее наоборот — пока последний находился в основном в зачаточном состоянии, эти требования уже формулировались для промышленного программирования; и те проекты, на которых в моём случае это выдвигалось, не предполагались ни для какого публичного открытия.
_>Когда опенсорс был зачаточном состояние, никаких git'ов ещё и в проекте не было, так что не очень понятно о каких базовых принципах ты говоришь.

Всё о тех же. Простые тупые системы уже были.

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

Именно так. И введение staging поэтому стало революционным расширением.

_>И чем же более подробная (а не приглаженная искусственно) история способна помешать долговременной работе над проектом? )

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

_>В документации указаны оба варианта (потому что не у всех стоит обязательно последняя версия Mercurial).

Ты даже не пытаешься понять, что я написал.
Мне пофиг, что что-то представлено ещё и в виде extension. Legacy — штука полезная (ограниченно во времени). Мне не пофиг, что вместо "закоммитить на выбор" команда описана как "сделать выбор, что коммитить", потому что последнее описание безусловно неадекватно.

N>>Если это тупик, полученный в результате конструктивного и ответственного применения того, что было известно до того — да, он должен быть документирован. Но не в коде (скорее всего, он должен остаться в немерженной ветке), а в сопроводительной документации и в историческом отчёте. Типа "для выбора варианта реализации структуры было измерено 4 версии (описание версий), тикет на измерение #143502, код и результаты измерений сложены в репо BigProject.aux".
_>Неудобный способ. Он подходит только в том случае, если в системе отслеживания задач есть только один способ её закрыть (типа удачно).

Он подходит ко всем вариантам закрыть задачу.

_> Если же есть нормальный способ

Пропаганда.

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

Они не левые. Код не заменяет документацию.
Если решено код попытки сохранить, он идёт в experiments/ или аналогичную иерархию веток, может — в отдельное репо. Висеть безымянной независимой головой ему не надо.
Но такое решение сохранить — нетипично.

N>>Если же это, как в >90% случаев, недоработка вида "а тут не учтён ещё один случай", "изменено 3 места применения, а ещё про 2 тупо забыто" и ловится коллегами на peer review — никакой причины "документировать" это где-то кроме поточных отчётов о проделанной работе — нет, и тем более — вечно сохранять эти ляпы и тестовые версии в коде. Там и без того будет достаточно случаев недоработки и кривой оценки.
_>А это тоже полезно сохранять, но уже для других целей. Так сказать административно-кадровых. )))

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

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

D>·> Да, их можно в разных префиксах (namespaces) разместить. Полное имя будет разным, конечно, но ты пока не объяснил необходимость неразличимых имён. "Сделать так как умеет hg" я как объяснение не приму. Ибо даже в оф доках так не рекомендуют делать.
D>С одинаковыми именами у меня вопрос: 2 дева работали над разными проблемами с базой данных и назвали свои ветки db_fix. Что получим на выходе? Как определить какая именно проблема решалась в какой ветке?
Их ветки будут иметь локальные названия db_fix, когда они решат обменяться коммитами, то чужие ветки появятся с префиксом remotes/ — их легко различить.
Из названия "db_fix" извлечь описание проблемы не выйдет никак, даже со всеми расширениями hg вместе взятыми.
Поэтому проблема должна быть описана в сообщениях коммитов или коммиты должны иметь линки в трекинговую систему. И hg тут не исключение.