Pourquoi git push gerrit HEAD:refs/for/master au lieu de git push origin master ?

Question

Je viens de commencer à utiliser gerrit et je veux savoir pourquoi nous devons faire git push gerrit HEAD:refs/for/master au lieu de faire git push origin master

Si je le fais git push origin master J'obtiens l'erreur suivante ! [remote rejected] master -> master (prohibited by Gerrit)

Answer 1

La documentation de Gerrit, en particulier le "Pousser les changements" section, explique que vous poussez jusqu'à la "magie". refs/for/'branch' ref en utilisant n'importe quel outil client Git".

L'image suivante est tirée de l'introduction à Gerrit . Quand on pousse vers Gerrit, on fait git push gerrit HEAD:refs/for/<BRANCH> . Cela pousse vos changements vers le aire de rassemblement (dans le diagramme, "Pending Changes"). Gerrit n'a pas réellement de branche appelée <BRANCH> ; il ment au client git.

En interne, Gerrit possède sa propre implémentation pour les piles Git et SSH. Cela lui permet de fournir la fonction "magique" refs/for/<BRANCH> arbitres.

Lorsqu'une demande de création d'une référence dans l'un de ces espaces de noms est reçue, Gerrit exécute sa propre logique pour mettre à jour la base de données, puis ment au client sur le résultat de l'opération. Un résultat positif fait croire au client que Gerrit a créé la référence, mais en réalité, Gerrit n'a pas créé la référence du tout. [ Lien - Gerrit, "Les détails croustillants". ].

Après un correctif réussi (c'est-à-dire que le correctif a été poussé vers Gerrit, [placé dans la zone de transit "Pending Changes"], révisé et que la révision a été acceptée), Gerrit pousse le changement de "Pending Changes" vers le "Authoritative Repository", en calculant dans quelle branche le pousser en se basant sur la magie qu'il a fait lorsque vous avez poussé vers refs/for/<BRANCH> . De cette façon, les correctifs révisés avec succès peuvent être tirés directement des branches correctes de l'arborescence de l'interface utilisateur. Authoritative Repository .