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

_>>Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )
N>Вот я читаю `hg help record` и вижу описание того, что она "interactively select changes to commit". Где находятся эти изменения, когда hg record уже отработала, а hg commit ещё не запускалась? Это то, по чему я предположил существование staging area. Видишь ли, в отличие от предположений коллеги woah, я читаю документацию и верю ей.
N>А вот сейчас проверил — hg record сразу коммитит. Значит, враньё с самого начала в документации — фраза "interactively select changes to commit" должна звучать на самом деле примерно как "commit interactively selected changes". Да, ты прав, всё ещё хуже, чем я предположил — в Hg нет staging, а в документации ещё один кусок гнилого обмана.
N>(А ещё в таком случае интересно, зачем такую пустую банальность, не дающую никаких потенциально неожиданных свойств, как staging area, прятать в выключенные по умолчанию расширения. Конспирология, но у меня нет никаких идей, кроме как то, что авторы Hg считают своих пользователей за полных дебилов, которые всё протеряют.)

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

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

_>>А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))
N>Кроме эмоциональных оценок в терминах "скрыть" и "косяк", всё верно. Первичная история — до начала взаимодействия с другими людьми — не должна быть историей косяков, она должна быть историей правильно сформированных и сгруппированных изменений. Ты предлагаешь хоть и маленький и временный, но _продукт_. Своей работы. Никого не должно волновать, сколько промежуточных косяков ты допускаешь по дороге, пока это укладывается в ограничения по ресурсам — на суд коллег должны быть вынесены результаты.

Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики.

N>А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них
N>* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение
N>* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать
N>* функциональное изменение по возможности максимально однородно по сути действий
N>и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.

Это похоже на какие-то опенсорсные заморочки. )))

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

У меня противоположное мнение. )

N>>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
_>>А как можно организовать цепочки без фиксации? )
N>Ключевое слово было "безымянных". Не делай вид, что не понял этого.

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