git-svn fetch holt nicht die neuesten Versionen herein

Question

Wenn ich eine

git svn fetch

aus meinem Repository, gibt es nichts zurück und aktualisiert sich nicht, obwohl es neue Commits gibt unter svn gibt.

[root]# svn log -l 1  http://example.com/trunk/client-resources/resource-pa
    r12958 | ing | 2011-08-22 18:29:57 -0500 (Mon, 22 Aug 2011) | 1 line
    SRGENERAL-1468 adding more arrays for pa
[root]# git-svn fetch
[root]# git log -1
    commit be19ae4c7d1a3c3da6dd90389aebd6d76792cc71
    Author: sltin <sltin@44b83e5a-25ef-0310-8dbe-ee0aa4f92a64>
    Date:   Wed Jun 22 14:30:53 2011 +0000

    Fixing the classpath.

    git-svn-id: http://example.com/trunk/client-resources/resource-common@12406 44b83e5a-25ef-0310-8dbe-ee0aa4f92a64

Beachten Sie die Versionsunterschiede. Das svn-Protokoll listet 12958 und das git-Protokoll listet die letzte svn-Version als 12406.

Ich kann einen Reset auf 12406 und dann einen neuen Abruf durchführen:

[root]# git svn reset 12406
    r12406 = be19ae4c7d1a3c3da6dd90389aebd6d76792cc71 (refs/remotes/git-svn)
[root]# git svn fetch
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12977 = 1b21f560b0354b28fe1a272d7723b1e6fa90a99c (refs/remotes/git-svn)
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12978 = bf22ea0151a364eb1ca1af37a7a907d5b5cc7420 (refs/remotes/git-svn)
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12987 = ce922c2eae07f6c12dbbd4175a9c61055b563ee3 (refs/remotes/git-svn)

Und wenn ich die Protokollversionen überprüfe, sind sie unverändert.

Wie bringe ich git-svn dazu, die neuesten Versionen von svn einzulesen?

Editar:

Ich habe die Antwort gefunden: Die svn-Daten werden in einen inaktiven Thread geladen, der normalerweise in den aktiven Zweig eingebunden wird, der in einem reinen Repository nicht existiert. Ich habe versucht, die Daten zurückzusetzen, aber auch dafür ist ein aktiver Zweig erforderlich. Die endgültige Antwort war:

git reset --soft refs/remotes/git-svn

Answer 1

git svn fetch kopiert nur neue Revisionen in Ihre lokale Objektdatenbank, ähnlich wie git fetch - beide synchronisieren nur Objektdatenbanken. Ihr Zweig und Ihre Arbeitskopie werden dadurch nicht aktualisiert. Um die neu geholten Änderungen in Ihren Zweig zu bekommen, verwenden Sie git svn rebase ; es wird alle Ihre lokalen Änderungen auf die letzte svn-Revision anwenden.

git svn rebase führt einen schnellen Vorlauf durch, wenn es keine lokalen Übertragungen gibt, so dass die Historie nicht beeinträchtigt wird. Alternativ könnten Sie verwenden git merge --ff-only git-svn um zur neuesten svn-Revision vorzuspulen (und abzubrechen, wenn sie nicht vorspulbar ist, d.h. kein direkter Nachkomme)

Sie sollten nur verwenden git svn reset wenn das Upstream-Svn die Historie geändert hat (svndump/svnadmin) und Sie die neuen Commits neu holen müssen, aber das sollte fast nie passieren (sonst ist der Admin schuld!)

Answer 2

Ich habe die Antwort gefunden: Die svn-Daten werden in einen inaktiven Thread geladen, der normalerweise in den aktiven Zweig eingebunden wird, der in einem bloßen Repository nicht existiert. Ich habe versucht, die Daten zurückzusetzen, aber auch dafür ist ein aktiver Zweig erforderlich. Die endgültige Antwort war:

git reset --soft refs/remotes/git-svn

Answer 3

Ich glaube, Sie wollen git svn rebase . Dies ist ein Unterschied zu git pull Sie ähneln sich jedoch insofern, als beide zwei Schritte umfassen (Abruf aus der Ferne und anschließende Neuspeicherung oder Zusammenführung).

Sie können auch nur bereits abgeholte Commits rebasen:

git svn rebase --local

Wenn Sie lokale Commits haben, die noch nicht im SVN sind, wird git-svn diese auf die neuesten SVN-Commits umschreiben.

Answer 4

Hat das gleiche Problem hier im Jahr 2018 mit der neuesten Git. Gelöst durch Entfernen der .rev_map y index Dateien und führen Sie erneut git svn fetch .

/.git/svn/refs/remotes/origin/trunk/.rev_map.<GUID>
/.git/svn/refs/remotes/origin/trunk/index

Irgendwie ist es bei der falschen letzten svn Revisionszuordnung im Cache hängen geblieben. In meinem Fall war es die r32-Revision, die eigentlich die r31-Revision war (weil r32 und r31 eindeutig unterschiedliche Commit-Nachrichten haben, so habe ich das entdeckt) und es hat die r32-Revision mit der Commit-Nachricht der r31-Revision angezeigt.

Vorsicht!

Hat sich ein weiteres Problem eingefangen. Die git pull origin trunk:master hat in meinem Fall die Änderungen vor der Neuindizierung rückgängig gemacht. Machen Sie also NICHT das Ziehen. Machen Sie die rebase y push vor dem pull um die korrigierten Änderungen an das entfernte Repository weiterzugeben.