Как запретить фабрикатору есть мою историю фиксации

Ответ 1

Вместо этого следует использовать собственный поток git, такой как git merge и git push. От фабрикатора arc documentation:

После того как изменения были приняты, вы обычно нажимаете их и закрываете пересмотр. arc имеет несколько рабочих процессов, которые помогают с этим:

* squashing or merging changes from a feature branch into a master branch
* formatting a good commit message with all the information from Differential
* and automatically closing the revision.

Вам не нужно использовать какой-либо из этих рабочих процессов: вы можете просто запустить gitpush, hg push или svn commit, а затем вручную закрыть ревизию с в Интернете.

arc намеренно уничтожает ваши коммиты.

Ответ 2

Ответ asherkin объясняет обоснование этого поведения и почему это значение по умолчанию.

Если вы не найдете этот аргумент убедительным, вы можете использовать флаг --merge для arc land для выполнения слияния --no-ff вместо --squash. Эти слияния не будут уничтожать локальные коммиты.

Если вы установили history.immutable в true в .arcconfig, arc land будет --no-ff слить по умолчанию.

Вы также можете использовать команды raw git, если вам не нравится поведение arc land; он предоставляется только для удобства.

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

Ответ 3

Существует некоторая документация, которая объясняет, почему это настройка по умолчанию для arc land.

Стратегия, в которой одна идея является одной фиксацией, не имеет никакого реального преимущества над любой другой стратегией, пока ваш репозиторий не достигнет скорости, когда он станет критическим. В частности:

• По сути, все операции с главным/удаленным репозиторием связаны с идеями, а не с фиксацией. Когда у одной идеи много коммитов, все, что вы делаете, более сложно, потому что вам нужно выяснить, какие коммиты представляют идею ( "виджет foo сломан, что мне нужно вернуть?" ), Или какая идея в конечном итоге представлена ​​фиксацией ( "commit af3291029 не имеет смысла, какой целью является это изменение, пытающееся выполнить?" ).
• Технология выпуска значительно упрощена. Инженеры-разработчики могут легко или легко выбирать идеи, когда каждая идея соответствует одному фиксации. Когда идея представляет собой несколько коммитов, становится легче случайно выбрать или отбросить половину идеи и в конечном итоге оказаться в состоянии, которое фактически гарантировано будет неправильным.
• Автоматическое тестирование значительно упрощается. Если каждая идея является одной фиксацией, вы можете запускать автоматические тесты против каждой фиксации, а ошибки тестирования указывают на серьезную проблему. Если в каждой идее много коммитов, большинство из этих коммитов представляют собой известное разбитое состояние базы кода (например, контрольная точка с синтаксической ошибкой, которая была исправлена ​​на следующей контрольной точке или с полупринятой идеей).
• Понимание изменений значительно упрощено. Вы можете делиться пополам и идентифицировать всю идею тривиально, не ловя вперед и назад в журнале, чтобы идентифицировать экстенты идеи. И вы можете быть уверены в том, что вам нужно, чтобы удалить всю идею.
• Нет четкого значения в том, что фиксация контрольной точки (некоторые из которых гарантируются как известные сломанные версии репозитория) сохраняются на пульте дистанционного управления. Рассмотрим теоретический VCS, который автоматически создает фиксацию контрольной точки для каждого нажатия клавиши. Очевидно, что этот VCS будет непригодным для использования. Но многие контрольно-пропускные пункты не сильно отличаются друг от друга, и концептуально представляют собой некоторую относительно произвольную точку в последовательности нажатий клавиш, которая вписывалась в большую идею. Избавьтесь от них или создайте слой абстракции (merge commits), который позволяет игнорировать их, когда вы пытаетесь понять репозиторий с точки зрения идей (что почти всегда).

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

Для git рекомендуемое решение состоит в том, чтобы вставлять ветки функций в восходящий поток, а затем объединять, а не переустанавливать на master - если вы согласны с вышеприведенными пунктами, но все же хотите, чтобы ваша контрольная точка совершила движение вверх по течению.

Если это только во время просмотра (как ваш вопрос сформулирован), но это также звучит так, будто вы не просматриваете код или просматриваете только пост-push-код с помощью Audit), обратите внимание, что Differential уже отображает все ваши локальные коммиты с исходным сообщением фиксации для просмотра рецензента.

arc land предназначен только для нажатия на "окончательную" ветвь репозитория (т.е. производство или какая-либо ветвь, представляющая изменения, ожидающие выпуска). Если вы выполняете проверку пост-push-фиксации (т.е. От слияния от разработки до мастера), вы можете просто обойти arc land (и общепризнано, что вам нужно во многих случаях) и git push ваши изменения напрямую.

Ответ 4

history.immutable: настраивает дугу для использования рабочих процессов, которые никогда не переписывают историю в рабочей копии. По умолчанию дуга будет выполнять некоторую переписку неопубликованной истории (изменение сообщений фиксации, слияние сквоша) на некоторых рабочих процессах в Git. Различия подробно описаны ниже.

просто добавьте строку в .arcconfig

"history.immutable": true