Чому використовується git push gerrit HEAD: refs / for / master використовується замість master git push origin

148

Я тільки почав використовувати герріт і хочу знати, чому нам потрібно це робити, git push gerrit HEAD:refs/for/masterа не робитиgit push origin master

Якщо я це зробити, git push origin masterя отримую повідомлення про помилку! [remote rejected] master -> master (prohibited by Gerrit)

git gerrit

— Шрайас
джерело

Відповіді:

259

Документація для Герріта, зокрема розділ "Натиснути зміни" , пояснює, що ви натискаєте на "магічний перегляд refs/for/'branch'за допомогою будь-якого інструмента клієнта Git".

Наступне зображення взято з «Інтро до Герріта» . Коли ти підштовхуєшся до Герріта, ти робиш git push gerrit HEAD:refs/for/<BRANCH>. Це підштовхує ваші зміни до області постановки (на діаграмі "Очікують зміни"). У Герріта насправді немає гілки, що називається <BRANCH>; це брехня клієнта git.

Внутрішньо у Gerrit є власна реалізація для стеків Git та SSH. Це дозволяє йому надати "магічні" refs/for/<BRANCH>відгуки.

Коли надходить запит на натискання на створення ref в одному з цих просторів імен, Герріт виконує власну логіку оновлення бази даних, а потім бреше клієнту про результат операції. Вдалий результат змушує клієнта повірити в те, що Герріт створив рефлекс, але насправді Герріт взагалі не створив його. [ Посилання - Джерріт, "Gritty Details" ].

Герріт робочий процес

Після успішного виправлення (тобто, патч було натиснуто на Герріт, [введення його в область постановки "Очікують зміни"), переглянуто, і огляд пройшов), Герріт переміщує зміни з "Очікують зміни" в " Авторитетний сховище ", обчислюючи, до якої гілки підштовхнути її, виходячи з магії, яку вона зробила, коли ви натиснули на refs/for/<BRANCH>. Таким чином, вдало переглянуті патчі можна витягнути прямо з правильних гілок Authoritative Repository.

— simont
джерело

Що з цікавості, що насправді відбувається, якщо ви робите щось на кшталт "git push origin"? Я спробував це і не бачу змін ніде, тому питання. Але він, природно, існує в моєму локальному журналі.

@Pintolaranja я зробив те саме випадково. Ви маєте рацію, Ґерріт "впорається" з такою ситуацією, але це не створює жодних змін. Тож насправді це зовсім не справляється. Що нас справді злить, бо це справді дурно. Чому дозволити користувачеві щось зробити, що Герріт не в змозі належним чином впоратися?

— trejder

@gregb Так. Стрілки вказують джерело та призначення команди, а не будь-який наступний потік даних у результаті. наприклад, розробник 1 видає авторитетний сховище, а не навпаки

— Гарет

@trejder Це дозволяє, тому що Герріт дозволяє налаштувати деякі облікові записи, щоб обходити огляди. Натискаючи на гілку за замовчуванням, ви фактично говорите: "Я хочу об'єднати цю зміну без огляду". Якщо вам це не дозволено, натискання не вдасться.

— Hounshell

Або ви не можете вживати геррі і взагалі уникати цього веселого безладу.

— C Джонсон

Щоб уникнути необхідності вказувати повністю команду git push, ви можете альтернативно змінити файл git config:

[remote "gerrit"]
    url = https://your.gerrit.repo:44444/repo
    fetch = +refs/heads/master:refs/remotes/origin/master
    push = refs/heads/master:refs/for/master

Тепер ви можете просто:

git fetch gerrit
git push gerrit

Це за словами Герріта

— Шон Мерфі
джерело

+1 від мене! Це набагато приємніше просто мати цей жорсткий код для мого, remote.origin.pushзамість того, щоб вводити / вставляти його кожен раз!

— DaoWen

@SeanMurphy Ви можете зробити це більш загальним, замінивши екземпляри "master" на "*", щоб щось на зразок "git push gerrit TopicBranch" також працювало.

— Девід Дорія

Крім того, якщо герріт - ваш єдиний пульт, його зовсім не потрібно вказувати. Я просто роблю git fetchі git pushз вищезгаданим config @DavidDoria.

— bernk

push = refs / heads / *: refs / for / * є для всіх відділень

— Victor

Вам дійсно потрібно використовувати гілку вище, ніж поточну гілку. У мене зазвичай паралельно відбувається десяток змін, тому використання однієї гілки просто не працює.

— Крістіан Гетце