Здравствуйте, Sharov, Вы писали:

N>>Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.

S>А есть сейчас какие-то аналоги gerrit'у для CR? Я с ним не работал, имеет смысл поизучать?

github, bitbucket и прочие — можно комментировать, можно ставить "согласен" / "не согласен", можно подключать CI.
gitlab, думаю, точно так же (не щупал ни разу).

Главное — есть заметные отличия в стиле. Gerrit не даёт возможность (или это неудобно) массово плодить всякие _именованные_ персональные фичеветки. Удобно работать с ограниченным набором целевых веток (у нас был master, а робот форкал от него всякие release90, release91...)
Временные ветки на предложения есть, но имени у них нет (можно поставить тег, но тег не уникален), только номер; получается, например, цепочка из ревью 123000, 123003, 123004... каждое надо рассмотреть и одобрить или отказать. Если все одобрены — можно отправить (какое-то ревью и всех его родителей) в целевую ветку, по их родителю видна эта ветка (соответственно master, release90 и так далее).
Зато он умеет, например, такое: сделал цепочку из 10 коммитов, в первом был заведен класс Foo. Пришёл главный ревьюер, сказал — нет, это должно быть Moo. Переименовал во всех коммитах, теперь у каждого из ревью есть patchset 1 и patchset 2. Их можно сравнить друг с другом, оно показывает даже разными цветами правки самого патчсета и правки, пришедшие из разных родителей (красный/зелёный и синий/жёлтый соответственно).
Вот [https://android-review.googlesource.com/c/platform/packages/modules/NeuralNetworks/+/1966946/]тут[/url], например, можно потыкать на публичном проекте (удобный пример, 10 выкатываний правки и цепочка коммитов это солидная история).

У github, bitbucket и прочих нет раздельного одобрямса на каждый коммит, хотя есть комментарии по строкам. Зато у них плоди именованные ветки сколько угодно, главное, не забывать их потом зачищать

Здравствуйте, Sharov, Вы писали:

N>>Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.

S>А есть сейчас какие-то аналоги gerrit'у для CR? Я с ним не работал, имеет смысл поизучать?

github, bitbucket и прочие — можно комментировать, можно ставить "согласен" / "не согласен", можно подключать CI.
gitlab, думаю, точно так же (не щупал ни разу).

Главное — есть заметные отличия в стиле. Gerrit не даёт возможность (или это неудобно) массово плодить всякие _именованные_ персональные фичеветки. Удобно работать с ограниченным набором целевых веток (у нас был master, а робот форкал от него всякие release90, release91...)
Временные ветки на предложения есть, но имени у них нет (можно поставить тег, но тег не уникален), только номер; получается, например, цепочка из ревью 123000, 123003, 123004... каждое надо рассмотреть и одобрить или отказать. Если все одобрены — можно отправить (какое-то ревью и всех его родителей) в целевую ветку, по их родителю видна эта ветка (соответственно master, release90 и так далее).
Зато он умеет, например, такое: сделал цепочку из 10 коммитов, в первом был заведен класс Foo. Пришёл главный ревьюер, сказал — нет, это должно быть Moo. Переименовал во всех коммитах, теперь у каждого из ревью есть patchset 1 и patchset 2. Их можно сравнить друг с другом, оно показывает даже разными цветами правки самого патчсета и правки, пришедшие из разных родителей (красный/зелёный и синий/жёлтый соответственно).
Вот тут, например, можно потыкать на публичном проекте (удобный пример, 10 выкатываний правки и цепочка коммитов это солидная история).

У github, bitbucket и прочих нет раздельного одобрямса на каждый коммит, хотя есть комментарии по строкам. Зато у них плоди именованные ветки сколько угодно, главное, не забывать их потом зачищать