История изменений

В mercurial переписывается запросто, до отправки на сервер. Да и там при желании можно разрешить. Как и в git определяется настройками сервера

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

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

Для этого сделано MQ, которое базируется на https://en.wikipedia.org/wiki/Quilt_(software) .

Так не занимайся такими играми, закоммить в локальную коп что успел - внесённые изменения точно не пропадут, - потом вернёшься к работе и сделаешь commit –amend

Одна из частых потребностей: выделить из сделанной за некоторый период работы часть правок, протестировать работоспособность проекта с этими правками, и релизнуть эту версию. Я очень хотел бы увидеть, как методика частых коммитов помогает упростить эту задачу. Сразу подчеркну, что в истории изменений не существует такой ревизии, которую я мог бы просто релизнуть, потому что я занимался несколькими задачами параллельно - и нет, создание 10 веток (на каждую мелкую фичу) за два месяца с последующим развлечением в их слиянии в разных комбинациях абсолютно неприемлимо. Также замечу, что я в основном корректирую именно правки, которые я сделал, то есть, вывод «git diff master...».

То есть, в случае Git я должен из моих локальных коммитов создать новую ветку, стереть в ней ненужные правки, отображаемые в «git diff master...», и дальше делать merge/rebase со squash/без. Поскольку squash+rebase является самым частым вариантом здесь, то я бы заметил, что по результату работы оно не отличается от применения патча, особенно учитывая, что автоматически собрать комментарии не получится и писать их придется ручками заново.

Теперь претензия, которую я предъявлял здесь уже несколько раз: зачем я тогда вообще создавал ветку и коммитил в нее свои правки? «hg update -m» по сути делает squash+rebase, получая тот же результат. При этом, я с тем же успехом могу дальше прыгнуть на другую ветку, потом на третью, а потом прыгнуть обратно на исходную ветку. В результате, вся операция делается за «hg update -m; hg shelve -k; правки; hg commit» либо «hg shelve -k; правки; hg update -m; hg commit» — я подчеркиваю, что здесь имеет место нулевая предварительная подготовка репозитория, я трогаю VCS только когда мне нужно.

Вторая упомянутая ранее претензия: да, Git теоретически позволяет проводить аналогичный сценарий, но в Git, как правило, это делать опасно и неудобно, и по этой причине пользующиеся Git люди вынуждены изучать наиболее простые и удобные пути работы с Git, которые как раз и сводятся к частым коммитам, rebase+squash, stash+pop и другим. Самые важные свойства VCS, на мой взгляд, — это не мешать и не терять пользовательcкие данные, и в этом плане Git весьма заметно проигрывает как Mercurial, так и Perforce. Git был создан, когда не было Mercurial и когда Perforce был платным, но в 2020 году нет ни одной причины пользоваться неудобным и опасным инструментом, когда есть более удобный и безопасный.

Не говоря о том, что reflog где хранится всё что было закоммичено, если уж совсем приспичит

Да, это резервные копии по-git-овски. Поскольку некоторые операции в Git деструктивны, то он сохраняет удаленные коммиты в reflog-е, позволяя теоретически их восстановить. Практически же в гробу я видал ваше восстановление - лучше дайте мне инструмент, который не будет заставлять меня восстанавливать потерянные данные.

Однако, Git не дает простых путей работаты с грязной репой

Так не работай с ней. Зачем самому себе проблемы создавать?

Потому что, внезапно, в SVN, Perforce, и Mercurial это делается очень просто и требует минимального взаимодействия с VCS. Чем-то напоминает: «мы раком ходим - и ты ходи. Ты что, дурак, прямо ходить? Так же упасть и лоб расшибить можно».

В mercurial переписывается запросто, до отправки на сервер. Да и там при желании можно разрешить. Как и в git определяется настройками сервера

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

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

Для этого сделано MQ, которое базируется на https://en.wikipedia.org/wiki/Quilt_(software) .

Так не занимайся такими играми, закоммить в локальную коп что успел - внесённые изменения точно не пропадут, - потом вернёшься к работе и сделаешь commit –amend

Одна из частых потребностей: выделить из сделанной за некоторый период работы часть правок, протестировать работоспособность проекта с этими правками, и релизнуть эту версию. Я очень хотел бы увидеть, как методика частых коммитов помогает упростить эту задачу. Сразу подчеркну, что в истории изменений не существует такой ревизии, которую я мог бы просто релизнуть, потому что я занимался несколькими задачами параллельно - и нет, создание 10 веток (на каждую мелкую фичу) за два месяца с последующим развлечением в их слиянии в разных комбинациях абсолютно неприемлимо. Также замечу, что я в основном корректирую именно правки, которые я сделал, то есть, вывод «git diff master...».

То есть, в случае Git я должен из моих локальных коммитов создать новую ветку, стереть в ней ненужные правки, отображаемые в «git diff master...», и дальше делать merge/rebase со squash/без. Поскольку squash+rebase является самым частым вариантом здесь, то я бы заметил, что по результату работы оно не отличается от применения патча, особенно учитывая, что автоматически собрать комментарии не получится и писать их придется ручками заново.

Теперь претензия, которую я предъявлял здесь уже несколько раз: зачем я тогда вообще создавал ветку и коммитил в нее свои правки? «hg update -m» по сути делает squash+rebase, получая тот же результат. При этом, я с тем же успехом могу дальше прыгнуть на другую ветку, а потом на третью. В результате, вся операция делается за «hg update -m; hg shelve -k; правки; hg commit» либо «hg shelve -k; правки; hg update -m; hg commit» — я подчеркиваю, что здесь имеет место нулевая предварительная подготовка репозитория, я трогаю VCS только когда мне нужно.

Вторая упомянутая ранее претензия: да, Git теоретически позволяет проводить аналогичный сценарий, но в Git, как правило, это делать опасно и неудобно, и по этой причине пользующиеся Git люди вынуждены изучать наиболее простые и удобные пути работы с Git, которые как раз и сводятся к частым коммитам, rebase+squash, stash+pop и другим. Самые важные свойства VCS, на мой взгляд, — это не мешать и не терять пользовательcкие данные, и в этом плане Git весьма заметно проигрывает как Mercurial, так и Perforce. Git был создан, когда не было Mercurial и когда Perforce был платным, но в 2020 году нет ни одной причины пользоваться неудобным и опасным инструментом, когда есть более удобный и безопасный.

Не говоря о том, что reflog где хранится всё что было закоммичено, если уж совсем приспичит

Да, это резервные копии по-git-овски. Поскольку некоторые операции в Git деструктивны, то он сохраняет удаленные коммиты в reflog-е, позволяя теоретически их восстановить. Практически же в гробу я видал ваше восстановление - лучше дайте мне инструмент, который не будет заставлять меня восстанавливать потерянные данные.

Так не работай с ней. Зачем самому себе проблемы создавать?

Потому что, внезапно, в SVN, Perforce, и Mercurial это делается очень просто и требует минимального взаимодействия с VCS. Чем-то напоминает: «мы раком ходим - и ты ходи. Ты что, дурак, прямо ходить? Так же упасть и лоб расшибить можно».