Git - comment afficher la liste de TOUS les objets dans la base de données

Essayer

 git rev-list --objects --all

---

Modifier Josh a fait un bon point:

 git rev-list --objects -g --no-walk --all

liste des objets accessibles à partir du ref-journaux.

Pour voir tous les objets dans l'inaccessible s'engage ainsi:

 git rev-list --objects --no-walk \
      $(git fsck --unreachable |
        grep '^unreachable commit' |
        cut -d' ' -f3)

---

Mettre tous ensemble, à vraiment obtenir tous les objets dans le format de sortie de rev-list --objects, vous besoin de quelque chose comme

{
    git rev-list --objects --all
    git rev-list --objects -g --no-walk --all
    git rev-list --objects --no-walk \
        $(git fsck --unreachable |
          grep '^unreachable commit' |
          cut -d' ' -f3)
} | sort | uniq

Pour trier la sortie en un peu plus utile (par le chemin de l'arbre/blobs, s'engage en premier) d'une | sort -k2 qui va regrouper tous les différents objets blob (révisions) pour les chemins identiques.

C'est plus juste, plus simple et plus rapide interprétation du script à partir des réponses par Marque et par willkill.

• Il utilise rev-parse --git-path pour trouver le objects répertoire, même dans un environnement plus complexe dépôt Git de l'installation (par ex. dans un multi-worktree situation ou que sais-je encore).

• Il évite tout recours inutile à l'find, grep, perl, sed.

• Si fonctionne normalement même si vous n'avez pas d'objets en vrac ou sans emballage (ou aucun des deux... si vous êtes enclin à exécuter sur une nouvelle référentiel).

• Il n'a, cependant, besoin d'un coup à partir de ce millénaire (2.02 ou plus récent, plus précisément, pour la extglob bits).

De partager et de profiter.

#!/bin/bash
set -e
shopt -s nullglob extglob

cd "`git rev-parse --git-path objects`"

# packed objects
for p in pack/pack-*([0-9a-f]).idx ; do
    git show-index < $p | cut -f 2 -d ' '
done

# loose objects
for o in [0-9a-f][0-9a-f]/*([0-9a-f]) ; do
    echo ${o/\/}
done

La git cat-file --batch-check --batch-all-objects commande, suggéré dans Erki Der Loony's réponse, peut être faite plus rapide avec la nouvelle Git 2.19 (T3 2018) option --unordered.

L'API pour itérer sur tous les objets appris à éventuellement les objets de la liste dans l'ordre où ils apparaissent dans packfiles, qui contribue à la localité des accès si l'appelant accède à ces objets, tout comme les objets sont énumérés.

Voir s'engager 0889aae, s'engager 79ed0a5, s'engager 54d2f0d, s'engager ced9fff (14 Août 2018), et s'engager 0750bb5, s'engager b1adb38, s'engager aa2f5ef, s'engager 736eb88, s'engager 8b36155, s'engager a7ff6f5, s'engager 202e7f1 (10 Août 2018) par Jeff King (peff).
^{(Fusionnés par Junio C Hamano -- gitster -- dans s'engager 0c54cda, 20 Août 2018)}

cat-file: support "unordered de sortie" pour --batch-all-objects

Si vous allez accéder au contenu de chaque objet dans une packfile, il est généralement beaucoup plus efficace de le faire dans le pack, plutôt que de hachage afin.
Qui augmente la localité de l'accès à l'intérieur de la packfile, qui à son tour est convivial, le delta de la base de cache, depuis le packfile met liées deltas uns à côté des autres.
En revanche, hash ordre est effectivement aléatoire, puisque le sha1 n'a pas perceptible
relation avec le contenu.

Ce patch introduit une "--unordered" option pour cat-file qui parcourt plus de packs le pack d'ordre sous le capot. Vous pouvez voir les résultats lors du déversement de tout le contenu du fichier:

$ time ./git cat-file --batch-all-objects --buffer --batch | wc -c
  6883195596

real 0m44.491s
user 0m42.902s
sys  0m5.230s

$ time ./git cat-file --unordered \
                    --batch-all-objects --buffer --batch | wc -c
  6883195596

real 0m6.075s
user 0m4.774s
sys  0m3.548s

Même sortie, un ordre différent, beaucoup plus rapide.
La même vitesse-up s'applique même si vous finissez par l'accès à l'objet contenu dans un
différents processus, tels que:

git cat-file --batch-all-objects --buffer --batch-check |
grep blob |
git cat-file --batch='%(objectname) %(rest)' |
wc -c

L'ajout de "--unordered" à la première commande de gouttes d'exécution dans git.git de 24 jusqu'à 3,5 s.

Note de côté: il y a en fait plus d'accélérations disponible pour le faire tous les processus maintenant. Puisque nous sommes à la sortie du contenu de l'objet pendant le pack itération, nous savons où trouver l'objet et ne pouvait ignorer l'extra de recherche fait par oid_object_info().
Ce patch s'arrête avant que l'optimisation depuis l'API sous-jacente n'est pas prêt pour nous de faire ces sortes de demandes directes.

Donc si --unordered est tellement mieux, pourquoi ne pas faire défaut? Deux raisons:

1. Nous l'avons promis dans la documentation --batch-all-objects sorties de hachage de l'ordre. Depuis cat-file est de plomberie, les gens peuvent être en s'appuyant sur ce défaut, et nous ne pouvons pas le changer.

2. C'est en fait plus lent pour certains cas.
   Nous avons pour calculer le pack revindex de marcher dans le pack de l'ordre. Et notre dé-duplication étape utilise un oidset, plutôt que d'une sorte-et-dedup, ce qui peut finir par être plus cher.

Si nous sommes juste à l'accès du type et de la taille de chaque objet, par exemple, comme:

git cat-file --batch-all-objects --buffer --batch-check

mon best-of-cinq chaude cache timings aller de 900ms à 1100ms à l'aide de --unordered.
S'il est possible, dans un froid-cache ou sous la pression de la mémoire que l'on pouvait faire mieux, car nous aurions la meilleure localité au sein de la packfile.

Et une dernière question: pourquoi est-il "--unordered" et non pas "--pack-order"? La réponse est encore deux fois:

1. pack"ordre" n'est pas bien définie de chose sur l'ensemble des objets. Nous sommes frapper les objets en vrac, ainsi que des objets en plusieurs packs, et la seule commande que nous sommes prometteur est dans un seul pack. Le reste est apparemment aléatoires.

2. Le point ici est de l'optimisation. Donc nous ne voulons pas de promettre toute commande particulière, mais seulement pour dire que nous allons choisir une commande qui est susceptible d'être efficace pour l'accès au contenu de l'objet.
   Ce qui laisse la porte ouverte à d'autres changements dans l'avenir sans avoir à ajouter une autre option de compatibilité

---

Il est encore plus rapide dans Git 2.20 (T4 2018) avec:

Voir s'engager 8c84ae6, s'engager 8b2f8cb, s'engager 9249ca2, s'engager 22a1646, s'engager bf73282 (04 Oct 2018) par René Scharfe (rscharfe).

^{(Fusionnés par Junio C Hamano -- gitster -- dans s'engager 82d0a8c, 19 Oct 2018)}

oidset: utilisation khash

Réimplémenter oidset à l'aide de khash.h afin de réduire son empreinte mémoire
et de le rendre plus rapide.

Exécution d'une commande qui vérifie principalement pour dupliquer des objets à l'aide de
un oidset, avec master et Clang 6.0.1:

$ cmd="./git-cat-file --batch-all-objects --unordered --buffer --batch-check='%(objectname)'"

$ /usr/bin/time $cmd >/dev/null
0.22user 0.03system 0:00.25elapsed 99%CPU (0avgtext+0avgdata 48484maxresident)k
0inputs+0outputs (0major+11204minor)pagefaults 0swaps

$ hyperfine "$cmd"
Benchmark #1: ./git-cat-file --batch-all-objects --unordered --buffer --batch-check='%(objectname)'

Time (mean ± σ):     250.0 ms ±   6.0 ms    [User: 225.9 ms, System: 23.6 ms]

Range (min … max):   242.0 ms … 261.1 ms

Et avec ce patch:

$ /usr/bin/time $cmd >/dev/null
0.14user 0.00system 0:00.15elapsed 100%CPU (0avgtext+0avgdata 41396maxresident)k
0inputs+0outputs (0major+8318minor)pagefaults 0swaps

$ hyperfine "$cmd"
Benchmark #1: ./git-cat-file --batch-all-objects --unordered --buffer --batch-check='%(objectname)'

Time (mean ± σ):     151.9 ms ±   4.9 ms    [User: 130.5 ms, System: 21.2 ms]

Range (min … max):   148.2 ms … 170.4 ms

---

Git 2.21 (T1 2019) optimise encore la codepath pour écrire commit-graphique, par
suivant le schéma habituel de la visite d'objets dans les en-pack de commande.

Voir s'engager d7574c9 (19 janvier 2019) par Ævar Arnfjörð Bjarmason (avar).

^{(Fusionnés par Junio C Hamano -- gitster -- dans s'engager 04d67b6, 05 Février 2019)}

Légèrement optimiser le "commit-graphique écrire" étape à l'aide de
FOR_EACH_OBJECT_PACK_ORDER avec for_each_object_in_pack().

Derrick Stolee ne ses propres tests sur Windows montrant à 2%
l'amélioration de la avec un haut degré de précision.

---

Git 2.23 (T3 2019) améliore "git rev-liste-des objets" qui a appris avec "--no-object-names" option pour piétiner le chemin de l'objet qui est utilisé comme un regroupement astuce pour pack-objets.

Voir s'engager 42357b4 (19 Juin 2019) en Emily Shaffer (nasamuffin).

^{(Fusionnés par Junio C Hamano -- gitster -- dans s'engager f4f7e75, 09 Juillet 2019)}

rev-list: enseigner --no-object-names pour activer la tuyauterie

Permettent de faciliter l'analyse par cat-file en donnant rev-liste une option pour imprimer
seulement l'OID d'un non-objet commit sans informations supplémentaires.

C'est un court terme de la cale; plus tard, rev-list doit être enseigné comment
imprimer les types d'objets qu'il trouve dans un format similaire à cat-file's.

Avant cette validation, la sortie de rev-list besoin d'être massé
avant d'être acheminé à un chat de fichier, comme ceci:

git rev-list --objects HEAD | cut -f 1 -d ' ' |
    git cat-file --batch-check

Cela a été particulièrement inattendue lorsque vous traitez avec de la racine des arbres, comme un
invisible les espaces à la fin de l'OID:

git rev-list --objects --filter=tree:1 --max-count=1 HEAD |
    xargs -I% echo "AA%AA"

Maintenant, il peut être transmis directement, comme dans l'ajout de cas de test:

git rev-list --objects --no-object-names HEAD | git cat-file --batch-check

Donc, c'est la différence entre:

vonc@vonvb:~/gits/src/git$ git rev-list --objects HEAD~1..
9d418600f4d10dcbbfb0b5fdbc71d509e03ba719
590f2375e0f944e3b76a055acd2cb036823d4b44 
55d368920b2bba16689cb6d4aef2a09e8cfac8ef Documentation
9903384d43ab88f5a124bc667f8d6d3a8bce7dff Documentation/RelNotes
a63204ffe8a040479654c3e44db6c170feca2a58 Documentation/RelNotes/2.23.0.txt

Et, avec --no-object-name:

vonc@vonvb:~/gits/src/git$ git rev-list --objects --no-object-names HEAD~1..
9d418600f4d10dcbbfb0b5fdbc71d509e03ba719
590f2375e0f944e3b76a055acd2cb036823d4b44
55d368920b2bba16689cb6d4aef2a09e8cfac8ef
9903384d43ab88f5a124bc667f8d6d3a8bce7dff
a63204ffe8a040479654c3e44db6c170feca2a58