Есть ли способ заставить Геррита отправить все коммиты в ветку на проверку кода?

Геррит объединит потенциально непроверенные изменения, которые были ранее в истории коммитов и находятся в другой «ветви» репозитория. Вот пример:

  1. касса филиал gerrit devel
  2. создать файл1.txt, добавить, зафиксировать, отправить в refs/heads/temp_branch
  3. создать файл2.txt, добавить, зафиксировать, отправить в refs/for/devel для проверки кода

Когда file2.txt принимается и объединяется, тогда file1.txt, поскольку он находится выше по течению, а не в отдельной ветке изменений, помеченной как находящейся на рассмотрении, также объединяется. Это потенциально очень проблематично, и единственное решение, которое я могу придумать, это принудительно проверять код каждого изменения, отправленного в каждую ветку. Это не идеально, так как вы можете захотеть иметь несколько ветвей с одной группой утверждающих или без проверки кода (для замены кода?).

Решение здесь состоит в том, чтобы заставить каждую фиксацию в истории помещаться в проверку кода, как это было бы в случае, если бы file1.txt не был перенесен в другую ветку в том же репозитории.

Есть ли в Gerrit настройка, которая накладывает это правило? Может ли кто-нибудь придумать рабочий процесс, который позволяет свободно переходить на refs/heads/, не рискуя загрязнить другие ветки?

Большое спасибо.


git gerrit
person mut1na    schedule 27.02.2012    source источник
comment
Я думаю, что в вашем примере шаг 2 действительно является нажатием на refs/for/temp_branch?   -  person Brad    schedule 28.02.2012

Ответы (1)


arrow_upward
2
arrow_downward

Я подозреваю, что вы видите такое поведение, потому что фиксация на шаге 3 имеет фиксацию на шаге 2 в качестве родителя. Вы не можете отправить коммит, если все его родители не были отправлены. Я согласен с вами, что это похоже на ошибку в Gerrit - он должен отказываться от отправки, пока не будет отправлен шаг 2.

Попробуйте этот обходной путь - добавьте шаг 2a после шага 2:

2а. проверить ветку devel еще раз

Если коммиты идут в 2 разные ветки, нет смысла делать их линейными.

Еще одна мысль — какую стратегию слияния вы используете для этого проекта? Если это вишневый выбор, я бы попытался изменить его на слияние, если это необходимо, или, если это не вишневый выбор, я бы попытался изменить его на вишневый выбор. Я считаю, что поведение здесь отличается между стратегиями слияния.

person Brad    schedule 28.02.2012
comment
Оказывается, этот недостаток был отмечен в Сайт Gerrit. Хотя вы были правы насчет вишенки! Я не уверен, доверяю ли я вишневым выборам с точки зрения конфликтов слияния, которые могут возникнуть из-за нескольких связанных изменений, проходящих проверку кода и, как правило, сохраняющих целостность истории коммитов. Но это решает проблему непреднамеренного слияния непроверенных изменений. - person mut1na; 29.02.2012
comment
просто чтобы добавить, выбор вишни по существу делает коммит в источнике «официальным» идентификатором коммита, когда он объединяется. Также это означает, что вам нужно перебазировать исходную ветку для ваших собственных изменений (хотя это будет тривиально - т. е. никаких конфликтов, так как у вас уже есть код!), поэтому ваша ветвь не расходится с источником. - person mut1na; 29.02.2012