web-dev-qa-db-fra.com

Impossible de déterminer les informations SVN en amont à partir de HEAD l'histoire

Pourquoi ai-je ce message d'erreur?

gitgit-svn
58
Chad

(Posté par la "question" de Chad comme réponse, mise en forme fixe et fautes de frappe.)

Ce message d'erreur peut avoir plusieurs causes.

Le premier, étant le plus commun. Votre référentiel git contient deux historiques disjoints: l'historique que vous avez créé dans git et l'historique du référentiel svn distant.

Pour résoudre ce problème, vous devez faire en sorte que votre référentiel git et votre référentiel svn partagent un ancêtre commun afin que git puisse déterminer quelles validations ont changé quoi.

L'article Article suivant explique comment résoudre le problème:

La deuxième cause possible du problème est si vous avez une première version de git (possible, le paquet windows msysGit) et que vous venez de créer un nouveau référentiel git qui communique avec un référentiel svn distant.

Par exemple:

git svn init svn://svn.xxx.xxx/xxx/trunk
git svn fetch -r BASE:10

ou

git clone svn://svn.xxx.xxx/xxx/trunk // Adds all the files in the revision...

Et vous obtenez les messages d'erreur suivants lorsque vous utilisez les commandes suivantes.

git svn info

Impossible de déterminer les informations svn en amont à partir de l'arbre de travail ou

git svn rebase

incapable de déterminer l'historique de l'arbre de travail des informations svn en amont ou

  git svn dcommit

Impossible de déterminer les informations SVN en amont à partir de l'historique HEAD

Si vous recevez les messages d'erreur ci-dessus, la première étape consiste à vérifier votre version de Git. Si vous exécutez une ancienne version de git <= 1.6.3.3. * Qui était dans mon cas avec (msysGit), le moyen le plus simple de résoudre le problème consiste à mettre à jour une version plus récente de git, telle que 1.6.4. *.

Ce qui suit Article présente le problème plus en détail.

33
bstpierre

j'ai eu ce message à cause du clonage du repo svn avec l'option --no-metadata. Peut-être que c'est le cas avec votre problème aussi. 

Lorsque vous le clonez sans cette option, tout va bien.

L'option --no-metadata est destinée à cloner un référentiel SVN lorsque le nouveau clone git doit devenir la source canonique à l'avenir. Il ne dispose pas de la capacité nécessaire pour s’engager dans le SVN en amont car il n’a aucun moyen de suivre les différences entre le clone git et le SVN en amont.

28
slafs

Dans mon cas, le HEAD du svn repo aurait dû être mis en correspondance avec le HEAD du git repo. This devrait résoudre le problème:

git update-ref refs/remotes/git-svn refs/remotes/Origin/master
14
axel22

J'ai reçu ce message après avoir ajouté de manière incorrecte le paramètre -s/--stdlayout à la commande git svn clone pour un dépôt Subversion disposant non de la "disposition Subversion standard" de trunk, tags et branches.

(Les dépôts de Subversion que je clone habituellement ont les chemins relatifs standard. Ainsi, lorsque j'ai cloné un dépôt Subversion qui ne les avait pas en utilisant ma commande git svn clone habituelle, j'ai reçu ce message crypté. Le message est correct à 100%, mais presque 100% inutile pour essayer de comprendre quel est le problème.)

9
Ed Ruder

vous avez le même problème, voici une solution basée sur http://eikke.com/importing-a-git-tree-into-a-Subversion-repository/ article:

$ git svn init http://server.com/svn/project/trunk/prototypes/proto1/
$ git svn fetch
  W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/svn/!svn/bc/100/dcom/trunk/prototypes/ws' path not found
  W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
  This may take a while on large repositories
  r147367 = 37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d (refs/remotes/git-svn)
$ svn log http://server.com/svn/project/trunk/prototypes/proto1/
  ------------------------------------------------------------------------
  r147367 | user | 2014-01-16 18:02:43 +0100 (Thu, 16 Jan 2014) | 1 line
  proto1 home
  ------------------------------------------------------------------------
$ git log --pretty=oneline master | tail -n1
  71ceab2f4776089ddbc882b8636aacec1ba5e832 Creating template
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #1

$ git show-ref git-svn
  37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d refs/remotes/git-svn
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ #2

$ echo "71ceab2f4776089ddbc882b8636aacec1ba5e832 37c9910f794cb9cff7ca0d5d2eb26e1f0dabbc4d" >> .git/info/grafts

$ git svn dcommit
  Committing to http://server.com/svn/project/trunk/prototypes/proto1 ...
    A   README.md
    A   pom.xml
A   src/main/Java/.gitkeep
A   src/main/resources/.gitkeep
A   src/main/webapp/WEB-INF/web.xml
A   src/main/webapp/index.html
A   webapps/.gitkeep
  Committed r147419
    A   README.md
    A   pom.xml
A   src/main/Java/.gitkeep
A   src/main/resources/.gitkeep
A   src/main/webapp/WEB-INF/web.xml
A   src/main/webapp/index.html
A   webapps/.gitkeep
  r147419 = 6a8bda7262739306d0a6e17eaad2802737dedc35 (refs/remotes/git-svn)
  No changes between current HEAD and refs/remotes/git-svn
  Resetting to the latest refs/remotes/git-svn
  Unstaged changes after reset:
    M   pom.xml
    M   src/main/webapp/index.html
    A   .gitignore
  Committed r147420
    M   pom.xml
    M   src/main/webapp/index.html
    A   .gitignore
  r147420 = 749b5acec55c341672bca08d07de8c336b5a4701 (refs/remotes/git-svn)
  No changes between current HEAD and refs/remotes/git-svn
  Resetting to the latest refs/remotes/git-svn
  ...etc...
8
andrej

Vous pouvez également obtenir cette erreur lorsque vous avez effectué un paiement sur un dépôt SVN fraîchement créé. 

J'ai résolu ceci par 

  1. Commencez par effectuer une validation initiale via la commande svn
  2. Puis clonez le référentiel à l'aide de la commande git svn. 
7
mohammadthalif

Une autre cause de ce problème est une mauvaise option svn-remote.svn.rewriteRoot (voir cette réponse pour des instructions sur l’utilisation de cela).

La ligne git-svn-id de vos commits importés de Subversion doit correspondre à l'URL rewriteRoot si elle est définie.

2
Daniel Hershcovich

J'ai reçu ce message parce que j'ai utilisé un nom de domaine complet pour la commande git svn init, mais que l'intégration git-svn préexistante utilisait uniquement le nom d'hôte.

Par exemple. grep git-svn-id a montré:

git-svn-id: svn://Host/repo/...

Mais je l'ai fait:

git svn init -Ttrunk svn://Host.domain.com/repo

(Nous avons une machine qui synchronise régulièrement un dépôt Git avec svn, alors tout le monde a git config --add remote.Origin.fetch refs/remotes/*:refs/remotes/* pour récupérer les branches svn synchronisées.)

2
Nathan Kidd

Autre cause possible: si vous avez un jeu de configuration svn-remote..rewriteUUID, git-svn risque d’avoir des difficultés à localiser les métadonnées appropriées pour le référentiel. Par exemple, vous pourriez avoir quelque chose comme ceci (voir la page de manuel git-svn pour une discussion sur les raisons pour lesquelles vous voudriez le faire):

[svn-remote "svn"]
    url = svn://read-write.test.org
    fetch = trunk/project:refs/remotes/trunk
    rewriteRoot = http://read-only.test.org/svn
    rewriteUUID = 1234-abcd

... où 1234-abcd est l'UUID du miroir en lecture seule. Lorsque vous 'git svn fetch', vous pouvez vous retrouver avec ce fichier:

.git/svn/refs/remotes/trunk/.rev_map.5678-dcba

... où 56780-dcba est l'UUID du référentiel en lecture-écriture. La solution est de:

$ mv .git/svn/refs/remotes/trunk/.rev_map.5678-dcba \
    .git/svn/refs/remotes/trunk/.rev_map.1234-abcd

Je ne peux pas dire avec certitude s'il s'agit d'une solution durable, c'est-à-dire qu'elle risque d'être confuse la prochaine fois que vous 'git svn fetch'. Peut-être essayer un lien symbolique plutôt que 'mv', je ne l'ai pas expérimenté.

0
szager

Je l'ai vu après avoir utilisé BFG Repo-Cleaner https://rtyley.github.io/bfg-repo-cleaner/ et réécrit l'historique de Git (intentionnel), puis j'ai essayé de nouveau de git svn fetch . Le message indique que la correspondance git <-> svn est perdue.

Pour résoudre ce problème, lisez https://git-scm.com/docs/git-svn
Tout en bas montre:

$ GIT_DIR/svn/* /. Rev_map.

Mappage entre les versions de Subversion nombres et noms de commit Git. Dans un référentiel où noMetadata Si l'option n'est pas définie, elle peut être reconstruite à partir des lignes git-svn-id: sont à la fin de chaque commit (voir la section svn.noMetadata ci-dessus pour plus de détails).

Pour ce faire, vous devez disposer des commentaires git-svn-id dans les commentaires de validation. Si vous le souhaitez, vous pouvez supprimer le fichier .rev_map. * Et le reconstruire.

rm .git/svn/refs/remotes/git-svn/.rev_map.*
git svn info

Cela devrait montrer:

Rebuilding .git/svn/refs/remotes/git-svn/.rev_map.{snip} ...
...
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.{snip}
Path: .
...and then regular git svn info output
0
mash