Versuch zu Gitolit Spiegel sagt "Sie sollten zuerst ziehen"

527
Mikhail T.

Einige der Repositorys, die wir verwenden, gitolitesind jetzt fehlerhaft mit:

% gitolite mirror push mirror-host repo/path remote: error: denying non-fast-forward refs/heads/feature/FOO-XXX-bar (you should pull first) ... ! [remote rejected] feature/FOO-XXX-bar (non-fast-forward)

Der aufrufende Benutzer gitolitebefindet sich in der @adminsGruppe, die die RW+Berechtigung für alles hat . Warum spult das Werkzeug nicht zurück?

Irgendwelche Vorschläge? Vielen Dank!

0
Welchen Teil der Nachricht verstehen Sie nicht? Ihre lokale Kopie ist nicht mehr aktuell (seit dem letzten Ziehen wurden neuere Änderungen auf dem Server vorgenommen). Sie müssen also zuerst ziehen, um diese Änderungen zu erhalten, bevor Sie sie weiterleiten. psusi vor 9 Jahren 0
Dies sind keine _arbeitenden Bäume, die gezogen werden können. Dies sind Repo-Spiegel, die _fetch_-ed sind. Sind Sie ein Gitolit-Benutzer, psusi? Wenn nicht, bitte nicht weiter teilnehmen. Vielen Dank. Mikhail T. vor 9 Jahren 0
Ziehen und drücken erfordert keinen Arbeitsbaum. Meistens schiebt man sich aus einem nackten Repo heraus und zieht aus ihm heraus. Der Server teilt Ihnen mit, dass Ihr lokales Repo und sein Repo voneinander abweichen. psusi vor 9 Jahren 0
Ja, ich weiß, dass die Repos unterschiedlich sind. Meine Frage ist, was Sie tun sollen. Wenn Sie einfach versuchen, "git pull" auf der Replik zu beantworten, antwortet: "fatal: / usr / bin / git-pull kann nicht ohne einen funktionierenden Baum verwendet werden." Mikhail T. vor 9 Jahren 0
Ahh, ja, für eine Zusammenführung ist ein Funktionsbaum erforderlich. Wenn Sie also versuchen, von einem reinen Repo zu einem anderen zu wechseln, müssen Sie entweder einen Funktionsbaum dort auschecken oder wenn bereits ein anderer Server vorhanden ist, müssen Sie dies tun Ziehen und lokalisieren Sie die Zusammenführung und schieben Sie das zum ersten Server, der dann zum zweiten Server schieben kann. psusi vor 9 Jahren 0
Ich denke, ich habe einen besseren Weg gefunden (unten). Mikhail T. vor 9 Jahren 0
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/22481/discussion-between-psusi-and-mikhail-t). psusi vor 9 Jahren 0

1 Antwort auf die Frage

0
Mikhail T.

Ok, das habe ich herausgefunden. Aus irgendeinem Grund enthielten die Repository / config-Dateien auf den Repliken die folgende Klausel:

[receive] denyNonFastforwards = true

Nachdem ich das kommentiert hatte, konnte ich rennen mirror push:

 ... + 5d7eb28...f0deef7 feature/FOO-XXXX-bar -> feaure/FOO-XXXX-bar (forced update) ...
Auf diese Weise haben Sie einfach alle neuen Änderungen auf dem Server zerstört / überschrieben (das bedeutet erzwungenes Update). psusi vor 9 Jahren 0
Bei dem Server handelt es sich um einen Standby-Modus, zu dem ohnehin nie ein Commit (Push) erfolgen soll. Aber ich denke, das Problem war auf ungültige Zeichen zurückzuführen, die in einigen "refs" verwendet wurden - die einzigen Repliken, die die Synchronisierung mit nicht schneller Vorwärtsbewegung abgelehnt haben, waren die, die _also_ ungültige Zeichen zuvor zurückgewiesen hat. Ich habe die Liste der gültigen Zeichen zuerst erweitert und jetzt sind Repliken auch genau das - Repliken. Mikhail T. vor 9 Jahren 0
Ich glaube nicht, dass es damit zu tun hat. Wenn das Replikat zuvor einfach einen Push abgelehnt hatte und nun für die Annahme konfiguriert ist, hätte es ohne die erzwungene Aktualisierung funktioniert. Die Tatsache, dass ein erzwungenes Update erforderlich war, deutet darauf hin, dass jemand * einen * divergenten Zweig dazu gedrückt hat, und Sie haben diesen divergenten Zweig rausgeworfen und durch Ihren eigenen ersetzt. Es sei denn, Sie haben Ihr Protokoll möglicherweise neu erstellt oder auf andere Weise umgeschrieben und als erzwungenes Update auf den ersten Server übertragen, und nur der zweite Server wurde so konfiguriert, dass erzwungene Aktualisierungen ablehnen. psusi vor 9 Jahren 0

Verwandte Probleme