git-p4 submit échoue avec "Not a valid object name HEAD~261".

Question

J'ai un dépôt git que j'aimerais mettre en miroir avec un dépôt Perforce. J'ai téléchargé le git-p4 script (la version la plus récente qui ne donne pas d'avertissements de dépréciation), et j'ai travaillé avec cela. J'ai compris comment extraire les modifications de Perforce, mais je reçois une erreur lorsque j'essaie de synchroniser les modifications du repo git. Voici ce que j'ai fait jusqu'à présent :

git clone git@github.com:asdf/qwerty.git
git-p4 sync //depot/path/to/querty
git merge remotes/p4/master     (there was a single README file...)

J'ai donc copié l'origine vers un nouveau directeur, j'ai obtenu une belle arborescence de fichiers fusionnés et git status montre que je suis à jour. Mais :

> git-p4 submit
fatal: Not a valid object name HEAD~261
Command failed: git cat-file commit HEAD~261

Ce fil de discussion sur la liste de diffusion git semble être pertinent, mais je n'arrive pas à comprendre ce qu'ils font avec tous les A, B, et C. Quelqu'un pourrait-il préciser ce que signifie "Not a valid object name" et ce que je peux faire pour résoudre le problème ? Tout ce que je veux faire est de prendre périodiquement un instantané de l'origine/maître dans Perforce ; un historique complet n'est pas nécessaire. Merci.

Answer 1

9 ans plus tard, ce problème pourrait disparaître avec Git 2.23 (Q3 2019).

Voir commettre c3f2358 (28 mai 2019) par Mike Mueller ( mdymike ) .
(fusionné par Junio C Hamano -- gitster -- en ajouter59c4 Le 17 juin 2019)

p4 unshelve : fix " Not a valid object name HEAD0 "sur Windows

git p4 unshelve a échoué avec ces erreurs :

fatal: Not a valid object name HEAD0
Command failed: git cat-file commit HEAD^0

(git version 2.21.0.windows.1, python 2.7.16)

En pOpen utilisé par git-p4 pour invoquer le git peut prendre soit un ou un tableau comme premier argument.
La forme tableau est préférée car l'échappement des caractères spéciaux sera géré automatiquement en fonction de la plate-forme.( https://docs.python.org/2/library/subprocess.html )
Le site extractLogMessageFromGitCommit utilisait cependant la méthode et donc le signe d'insertion ( ^ ) dans le champ HEAD^ L'argument 0 n'était pas échappé sous Windows.
Le signe d'insertion se trouve être le caractère d'échappement, ce qui explique pourquoi la commande git recevait HEAD0 .

Le comportement peut être confirmé en tapant ECHO HEAD^0 a qui émet HEAD0 .

La solution est simplement d'utiliser le format tableau pour transmettre la commande à fOpen qui est de toute façon recommandé et utilisé dans d'autres parties de ce code.

Answer 2

fatal: Not a valid object name

devrait signifier que d'une manière ou d'une autre le HEAD de la télécommande pointe vers une référence incorrecte.
En d'autres termes, lorsque vous faites un import P4 dans un repo git, il n'y a aucun moyen de soumettre ce repo git à P4, à cause d'un SHA1 incorrect. Pourquoi ? Je ne le sais pas.

C'est pourquoi, dans le fil que vous mentionnez, l'utilisateur :

• clonez le repo P4 dans B avec --import-local ("Importation dans refs/heads/ pas refs/remotes "),

• faire B (le clone Git du repo p4) un Repos brut (vous n'y travaillerez donc jamais, puisque son arbre de travail est vide)

• fixer le HEAD de B pour référencer la branche maîtresse p4 importée dans B

• cloner B dans C, un repo non vide (son arbre de travail n'est pas vide, vous pouvez y travailler)

B n'était là que pour l'importation initiale.

Le reste du travail est effectué en C (qui n'a pas de problème de SHA1 incorrect) avec :

• git-p4 sync (à déclarer en C remotes/p4/master en plus de remotes/origin/* )
• git-p4 submit