2014-02-21 11 views
5

Pushing Änderungen an Gerrit erfordert den eher esoterischen Befehl„git push“ zu Gerrit mit einem Tracking-Zweig

git push origin HEAD:refs/for/branchname

Wir haben das Drehbuch, aber ich bin auf der Suche nach einer Möglichkeit, diese nativ zu tun. Mit der mächtigen Konfiguration von git sieht es so aus, als könnte ich das meiste davon vorkonfigurieren [1], so dass nur git push ... fast ausreicht. Ich bin auf der remote.<name>.push refspec fest.

Ich kann bereits eine Tracking Thema Zweig erstellen, so dass git pull (keine anderen Parameter) Änderungen von Upstream-Remote in meinem Zweig Zweig ziehen. Jedoch mit Gerrit, dem Push-und holt refspecs ist nicht die gleiche: eine Fetches (Merges) von refs/heads/trackbranch, aber man drückt auf refs/for/trackbranch [2]

ich push Refspec in remote.<name>.push konfigurieren können, aber die Syntax ist ziemlich einfach : Wenn ich setze push = refs/heads/*:refs/for/*

Dann wird versuchen, meine t-foo Zweig zu refs/for/t-foo schieben. Aber git hat die Information, dass t-footrackbranch verfolgt. Kann ich eine refspec so definieren, dass git automatisch versucht t-foo auf refs/for/trackbranch zu schieben?

Wir verwenden derzeit ein Skript, um dies zu tun, und ich könnte ein Push refspec für jeden Zweig Zweig definieren (möglicherweise durch mehr Skripting). Ich hoffe, es gibt eine native Art, dies zu tun, so dass wir uns nicht auf mehr benutzerdefinierte Inhouse-Skripte für unser Team verlassen müssen.

[1] durch einen Tracking-Zweig mit git checkout origin/upstream_branch -b topic_branch definieren oder innerhalb einer bestehenden Niederlassung git branch --set-upstream-to origin/upstream_branch

[2] refs/for/* drängen schafft eine changeset für die Überprüfung. Mit entsprechenden Berechtigungen könnte man auf refs/heads/* drücken, um die Überprüfung zu umgehen, aber das negiert den meisten Punkt von Gerrit.

+0

"Kann ich einen refspec so definieren, dass git automatisch versucht, ein beliebiges t-foo auf seinen refs/for/trackbranch zu schieben?" Nein, zumindest denke ich das heute nicht. Was Sie erreichen wollen, ist die 'fetch = ...' Mapping-Maschine, die git mit Merge-Namen verwendet (um 'remote =' und 'merge =' parts) zuzuordnen, und das scheint nirgendwo verfügbar zu sein. Sie könnten ein Programm schreiben, das Ihre lokalen Zweige durchkämmt und all dies berechnet (aktualisiert dann Ihre gitconfig). Immer noch ein bisschen schmerzhaft. – torek

+0

Ja, das möchte ich machen. Wenn dies bestätigt wird, warum nicht als Antwort? –

+1

Nach mehr Suche, meine Frage ist ähnlich zu http://stackoverflow.com/questions/7101145/how-to-configure-specific-upstream-push-refspec-for-git-when-used-with-gerrit von zwei Jahren her und http://stackoverflow.com/questions/14320363/push-current-branch-to-gerrit vom letzten Jahr –

Antwort

1

Haben Sie in das Git-Review-Plugin geschaut? Es sollte ziemlich glücklich sein!

https://pypi.python.org/pypi/git-review

+0

Ich habe nicht und es sieht interessant aus, aber es ist immer noch ein zusätzliches Skript, anstatt mit git umfangreiche native Funktionen (Wir haben uns bereits von der Verwendung unseres selbstgewählten "Topic Branch" -Tagging zugunsten der "Tracking" -Funktion von git entfernt. Es ist frustrierend, denn es sieht so aus, als ob fast alles da ist, bis auf dieses letzte Glied in der Kette. –

+0

Ich sehe, was Sie meinen, aber bedenken Sie, dass git einmal fast keine nativen Funktionen rund um die Versionskontrolle hatte. Es ist im Kern ein inhaltsadressierbares Dateisystem. Alles andere wuchs als kleine Add-On-Skripte, die schließlich in C für Geschwindigkeit portiert wurden. git-review ist so "nativ" wie alles andere, in gewissem Sinne ... – gepoch

2

Aus irgendeinem Grunde :-) Ich ging weiter und versuchte, ein Skript zu schreiben git config-Einträge zu setzen, und dann festgestellt, dass es scheint keine Möglichkeit zu geben direkt die gewünschten Ergebnisse zu erzielen.

Als Alternative habe ich ein Skript, das auf die „gerrit Bewertung Name“ (Anmerkung schiebt: Ich habe nicht wirklich verwendet gerrit so dass diese im Wesentlichen nicht getestet ist, obwohl ich es mit der --dry-run Option ausgeführt haben und es sieht so aus, als ob es das Richtige ist - aber ich nehme an, dass du es vielleicht modifizieren willst. Natürlich ist das wahrscheinlich funktional dasselbe wie ein eigenes Skript.

Wie auch immer, Sie könnten dann einen globalen oder systemweiten Alias ​​haben, git config alias.review oder so ähnlich, der das Skript ausführt, so dass Sie git review oder git review branch sagen könnten. Der Alias ​​wäre nur review = !sh /path/to/script (Argumente werden zu diesem Zeitpunkt automatisch übergeben).

Ich legte das Skript hier: http://web.torek.net/torek/git/gerrit-review.sh.txt (die .txt Erweiterung ist nur so, dass Browser es standardmäßig anzeigen, anstatt es standardmäßig herunterladen).