2011-01-10 6 views
48

Ich benutze Git als Frontend zu Subversion (über Git Svn).Git: Warnung: refname 'xxx' ist mehrdeutig bei der Verwendung von git-svn

Also, für jeden Svn Stamm/Zweig habe ich Remote-Zweig in Git namens "Fernbedienungen/xxx". Zum Beispiel "remotes/trunk", "remotes/coolfeature".

Jetzt möchte ich einen "default" lokalen Zweig für jeden entfernten Zweig haben, um ihn für dcommit zu verwenden. Das Problem ist, dass ich eine solche Zweige wollen nach Subversion Zweige genannt werden, wie „Stamm“, „coolfeature“, so habe ich die folgenden Zweige in git:

trunk 
coolfeature 
remotes/trunk 
remotes/coolfeature 

Das Problem ist, dass jedes Mal, wenn ich „trunk Referenz "oder" coolfeature "git beschwert sich Zweig Name ist mehrdeutig. Keine große Sache, aber ich fühle mich unwohl.

Die Frage ist, wie kann ich mit dieser Warnung umgehen, unter der Annahme, dass das einfache Umbenennen von Zweigen nicht das ist, was ich tun möchte. Was sind die besten Praktiken für solche Fälle? nur für einzelne Repository, auslassen --global Flag

git config --global core.warnambiguousrefs false 

Wenn Sie dieses Verhalten wollen:

+3

ich bin nicht sicher. Ich habe das vermieden, indem ich einfach andere, aber ähnliche Namen gewählt habe. Sie können jedoch versuchen, 'refs/heads/trunk' oder vielleicht auch nur' heads/trunk' zu verwenden. Ich denke, das sollte funktionieren. – MatrixFrog

Antwort

40

Wenn Sie die --prefix=svn/ Flag an den git svn clone Befehl übergeben, dann alle der Subversion Zweige würde wie remotes/svn/branchname genannt werden. Wenn dies für Sie akzeptabel ist, behebt es die Warnung "Refname ist mehrdeutig". Es gibt Ihnen auch eine schöne Art und Weise zu den entfernten svn Zweige der Bezug genommen wird, wie in zum Beispiel, wenn Sie einen lokalen Tracking-Zweig erstellen möchten, es wäre so etwas wie:

$ git checkout -b branchname svn/branchname

Die lokale Niederlassung hat dann die gleiche Name als Remote-Svn-Zweig und kein mehrdeutiges Refname-Problem.

+19

Wie kann ich ein Repository reparieren, das ich bereits geklont habe, um '--prefix = svn /' zu haben? –

+0

Ich klonte einfach in ein neues Verzeichnis und holte dann die lokalen Zweige, die ich aus dem anderen Verzeichnis hatte: git fetch ../other_dir branch_name: branch_name --- Tab-Vervollständigung ist auch für die Branch-Namen großartig. – EnigmaCurry

+1

Wenn Sie bereits eine Verzweigung mit demselben Namen erstellt haben, können Sie Ihre Verzweigung mit diesem Befehl umbenennen: git branch -m [aktuellerName] [neuerName] – MikeD

13

Wenn Sie nur von Warnung loswerden wollen, setzen Sie core.warnAmbiguousRefs zu false.

+0

Ich habe wahrscheinlich alle bekannten/unbekannten Regeln hier verletzt, aber ich habe versucht "Git-Tag -a HEAD-M 'Start von Repo'" auf einem neuen Repo, nach dem ich die OPs Fehlermeldung erhalten. Die in diesem Beitrag beschriebene Lösung ermöglichte es mir weiter zu arbeiten. – bakoyaro

1

Es kann möglich sein, dass Sie einen anderen "Stamm" und "Coolfeature" als Tag haben. In diesem Fall weiß git nicht, ob Sie auf einen Zweig oder ein Tag verweisen. Benennen Sie die Tags und überprüfen, ob git Bericht nicht „mehrdeutig“ Name

+0

Dies ist nicht der Fall für mich. '.git/refs /' enthält eindeutige Namen. Ich habe keine Tags. Was veranlasst Git, sich an erster Stelle zu beschweren? –

0

Um die Konfliktmeldungen zu vermeiden, wenn die lokalen Niederlassungen beziehen, Präfix sie mit head/

zum Beispiel den in Konflikt stehenden Zweig topic

$ git diff topic remotes/topic 
warning: reframe 'topic' is ambiguous. 
... 

wird

$ git diff heads/topic remotes/topic 
...