Здравствуйте, alex_public, Вы писали:
_>>>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему). N>>Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор. _>Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )
Вот я читаю `hg help record` и вижу описание того, что она "interactively select changes to commit". Где находятся эти изменения, когда hg record уже отработала, а hg commit ещё не запускалась? Это то, по чему я предположил существование staging area. Видишь ли, в отличие от предположений коллеги woah, я читаю документацию и верю ей.
А вот сейчас проверил — hg record сразу коммитит. Значит, враньё с самого начала в документации — фраза "interactively select changes to commit" должна звучать на самом деле примерно как "commit interactively selected changes". Да, ты прав, всё ещё хуже, чем я предположил — в Hg нет staging, а в документации ещё один кусок гнилого обмана.
(А ещё в таком случае интересно, зачем такую пустую банальность, не дающую никаких потенциально неожиданных свойств, как staging area, прятать в выключенные по умолчанию расширения. Конспирология, но у меня нет никаких идей, кроме как то, что авторы Hg считают своих пользователей за полных дебилов, которые всё протеряют.)
_>А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))
Кроме эмоциональных оценок в терминах "скрыть" и "косяк", всё верно. Первичная история — до начала взаимодействия с другими людьми — не должна быть историей косяков, она должна быть историей правильно сформированных и сгруппированных изменений. Ты предлагаешь хоть и маленький и временный, но _продукт_. Своей работы. Никого не должно волновать, сколько промежуточных косяков ты допускаешь по дороге, пока это укладывается в ограничения по ресурсам — на суд коллег должны быть вынесены результаты.
А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них
* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение
* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать
* функциональное изменение по возможности максимально однородно по сути действий
и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.
И реально сложное изменение такого рода не сделать без возможности разделения, перестановки, слияния коммитов, выбора нужного из локальных изменений. А если какое-то современное средство прячет эту функциональность поглубже (отдельные команды, выключенные по умолчанию расширения), то его авторы целенаправленно воспитывают ламеров и говнокодеров.
N>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией. _>А как можно организовать цепочки без фиксации? )
Ключевое слово было "безымянных". Не делай вид, что не понял этого.
N>>Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.
_>А что ты называешь качественным результатом то? ) Мне казалось это должна быть идеально работающая последняя ревизия. Но у тебя это похоже что-то иное... )))
