Список связанных номеров наборов исправлений Gerrit для локальной ветки, загруженных через git-review

Номер набора исправлений Gerrit, связанный с локальной веткой, загруженной с помощью git-review

Рассмотрим изменение в Gerrit, скажем, изменение 1234, имеющее следующие наборы исправлений.

# Gerrit change 1234 (https://mygerrit.somewhere.net/#/c/1234/)
1 (original commit)
2 (some amendments)
3 (some amendments)

И что я извлекаю набор исправлений 2 изменения, используя git-review:

$ git review -d 1234,2
Downloading refs/changes/00/1234/2 from gerrit
Switched to branch "review/foo_bar/1234"

Вопрос:

  • Находясь в ветке review/foo_bar/1234 (без изменений после команды review выше), можно ли каким-то образом запросить номер набора исправлений Gerrit, связанный с веткой? т.е.

    $ ... ?
    2
    

Единственный подход, который я придумал, — это использовать git ls-remote для идентификации всех номеров наборов исправлений (и связанных с ними хэшей SHA) для данного изменения, а затем сравнить хэши с хэшем локальной ветки HEAD (git rev-parse HEAD) . В качестве альтернативы можно просто сопоставить хэш локального HEAD с git ls-remote и извлечь оттуда номер набора патчей, но я надеялся на более аккуратный подход.


person dfrib    schedule 23.11.2017    source источник


Ответы (1)


Вы можете запросить gerrit, используя интерфейс запроса ssh и идентификатор коммита. Например, если мой пульт gerrit...

$ git remote -v
gerrit  ssh://[email protected]:29418/openstack/tripleo-quickstart.git (fetch)

... тогда я могу сделать такой запрос gerrit:

ssh -p 29418 [email protected] gerrit query $(git rev-parse HEAD)

Ради прикола я схватил набор патчей 415754, который дает мне:

$ git log -1
commit c5852f3f29f0a08236261772e8cd892eba381597 (HEAD -> review/leif_madsen/415754)

Если я выполню приведенный выше запрос ssh ..., я верну кусок текста, который будет включать что-то вроде:

  patchSets:
    number: 1
    revision: a8eedf9e6c87f6542ea1802a493d9d5caa7acaa2
    [...]
  patchSets:
    number: 2
    revision: c5852f3f29f0a08236261772e8cd892eba381597
    [...]

Просто найдите набор исправлений, соответствующий вашему текущему идентификатору коммита. В данном случае вы можете видеть, что у меня патчсет 2.

Вы можете автоматизировать это, (а) запрашивая вывод JSON с помощью --format json и (б) используя инструмент запросов JSON, такой как jq:

$ ssh -p 29418 [email protected] gerrit query \
  $(git rev-parse HEAD) --patch-sets --format json |
  head -1 | jq '.patchSets[] |
  select(.revision=="'"$(git rev-parse HEAD)"'").ref'

Что производит, в этом случае, вывод:

"refs/changes/54/415754/2"
person larsks    schedule 23.11.2017
comment
Спасибо! Я намеренно ограничил свой вопрос, чтобы не включать более сложный случай (сам я понятия не имею, как к этому подойти), когда локальный HEAD был изменен (исправлен): есть ли у вас какие-либо мысли о том, как можно подойти к случаю, когда хэш HEAD больше не соответствует ни одному хэшу PS (дескриптор: выяснить, на каком PS HEAD был основан)? Скажем, для варианта использования с хуком фиксации, который предупреждает пользователя, если PS, на котором была основана HEAD локальной ветки, не соответствует самому последнему на gerrit. - person dfrib; 23.11.2017
comment
Это просто. В этом случае ваш запрос gerrit вернет 0 результатов; ответ JSON будет выглядеть примерно так: {"type":"stats","rowCount":0,"runTimeMilliseconds":4,"moreChanges":false}. Вы можете легко проверить это в сценарии. - person larsks; 23.11.2017
comment
Возможно, я был немного неясен в своем последнем комментарии, извините за это: сложная часть в этом «жестком сценарии» заключается не в том, как проанализировать, присутствует ли PS (HEAD) уже или нет на геррите, а в том, как (как я писал ,я даже понятия не имею какой-то локальный дикт.кеширование которого ПС был скачан последним для данного изменения?) посмотреть были ли данные новые еще не запушенные ПС основаны на самом последнем герритном ПС или нет. В моем примере создание новой PS(/amendment) на основе 2 приведет к предупреждению/подсказке от ловушки, тогда как новая PS на основе 3 — нет. - person dfrib; 23.11.2017