Comments 8
Прежде чем идти дальше, нам надо разобраться с параметром autosync. Если он включен ( «on», или 1 ), то при выполнении команды fossil update будет предпринята попытка получить сначала обновление из удаленного репозитория (pull), а при выполнении fossil commit — сначала pull и update, а сразу после commit — push ( передача изменений в удаленный репозиторий ), причем адресом удаленного репозитория будет указанный в последней выполненной команде clone, push, pull, sync, remote-url.Это прямо противоречит цели сохранения истории «как она есть». При включении
autosync вы получаете автоматический rebase последних изменений, что очевидно является сменой контекста, в котором делались изменения. Особенно, если алгоритм слияния где‐то напортачил (потому что неидеален, или, скорее, от того, что не понимает суть изменений: к примеру, при проведении рефакторинга на одной стороне при автоматическом слиянии вы вполне можете воткнуть в середину блока код с несуществующей переменной из‐за того, что та была переименована на другой стороне, а близкое окружение вашего кода данной переменной не содержало).
А какова альтернатива?
Одну вы и сами написали: «нерекомендуемые» микро‐ветки. Вторая: сделать всё это самому, но перед commit просмотреть diff, просмотреть комментарии (а в особо запущенных случаях и diff’ы: актуально, если из пояснения к изменению ничего не понятно или из комментария понятно, что изменение, вероятно, затрагивает ваш код) новых изменений и прогнать тесты.
В принципе, вы правы, это, в общем случае, более безопасное решение. И развилка на Timeline в случае fork более адекватно описывает ситуацию, чем прямая. Но в реальных ситуациях участники проекта часто работают над малопересекающимися областями и делать каждый раз fork с последующим изучением нового кода и merge — лишние и бесполезные трудозатраты. К тому же при наличии элементарного порядка в организации труда ситуации, когда кто-то, допустим, изменил название переменной, используемой другими, предварительно это не обсудив ни с кем, и даже не предупредив об этом — такие ситуации практически исключены.
Обычно при организации параллельной работы над непересекающимися вещами используют отдельные ветки и проблема не возникает вообще. А «изменение названия переменной» — не единственная вещь, которая может сломать код, и учесть их все практически невозможно. Поэтому fetch, test, review, rebase или merge, а не что‐то ещё. При отдельных ветках для каждой из таких непересекающихся областей и с нормальными разработчиками (в т.ч. не забывающими обсудить потенциально проблемные изменения) review много времени занимать не должен.
Кстати, я правильно понял, что аналога
git config remote.{name}.url {url}/echo $'[paths]\n{name} = {url}' >> .hg/hgrc для связывания URL с именем нет? Я что‐то в документации такого не вижу.Прямого аналога нет. Но того же эффекта можно, наверное, добиться, если вызывать push, pull из bash-скрипта, где предварительно по нужным правилам устанавливать URL — fossil remote-url…
Хотя я, честно говоря, не понял, для чего это нужно и как работает ваша конструкция.
Хотя я, честно говоря, не понял, для чего это нужно и как работает ваша конструкция.
Обе конструкции запоминают данный
Нужно это, если у вас два remote репозитория: например, upstream, из которого вы берёте изменения (и который, скорее всего, вам не доступен на запись), и собственный форк.
{url} под именем {name}, так что в дальнейшем можно будет писать имя везде, где требуется данный URL. Первая конструкция для git, вторая для mercurial.Нужно это, если у вас два remote репозитория: например, upstream, из которого вы берёте изменения (и который, скорее всего, вам не доступен на запись), и собственный форк.
Sign up to leave a comment.
Системы контроля версий: Fossil, часть II