Dans git, le hachage de révision actuel est stocké dans
.git/refs/heads/master
3 Réponses :
Je ne suis pas un expert mercurial, mais en prenant l'approche de Sledgehammer et que vous effectuez un GREP pour le hachage de révision actuel en .hg ne donne qu'un seul possible, et c'est Je crois que cela met en cache toutes les têtes du référentiel, il peut donc avoir plusieurs entrées. Par défaut, je pense qu'il aura toujours deux entrées, une pour la branche par défaut et une pour le numéro de révision de la pointe.
Je pense que les succursales.Chache est reconstruite chaque fois que de nouvelles modifications arrivent, il doit donc toujours avoir le hachage de révision actuel correct. .hg / brancheheads.Cache .
grep pour la version binaire :) (c'est en fait dans .hg / dirstate )
Assez juste - je devrais verrouiller ce slgegehammer loin et engager le cerveau.
Le problème est qu'il affiche les têtes de la succursale et sera incorrecte dans l'affichage du Rev actuel si vous n'êtes pas sur une tête de branche. (via hg up 3 si la pointe et toutes les autres branches sont plus élevées)
$ hg parents --template="{node}\n"
52b8cee1e59c91b9147635b7f44a3a8896ee0b00
$ hexdump -n 20 -e '1/1 "%02x"' .hg/dirstate
52b8cee1e59c91b9147635b7f44a3a8896ee0b00
But why can't you just call hg parents --template="{node}\n"?
Je suis impressionné par vos compétences binaires :)
Heh, je viens d'ouvrir Dristate.py et remarqua que les deux matchs des deux premières octets de DriState.py. Un peu de googling m'a eu la chaîne de formatage hexdump appropriée (Dieu ces choses sont affreuses).
hg id -debug -i -r.
La question posée "sans appeler hg"