Ich versuche, die GitHub v3-API zu verwenden, um die vollständige Liste der Commits zwischen zwei SHAs zu erhalten, indem ich die Vergleichs-API ( /repos/:owner/:repo/compare/:base...:head ), aber es gibt nur die ersten 250 Commits zurück und ich muss sie alle holen.
Ich habe die API-Paginierungsdokumente gefunden, aber die Vergleichs-API scheint weder page zu unterstützen noch oder per_page -Parameter, entweder mit counts oder SHAs ( EDIT : Der Parameter last_sha funktioniert auch nicht). Und im Gegensatz zur Commits-API scheint die Vergleichs-API keinen Link HTTP-Header zurückzugeben.
Gibt es eine Möglichkeit, das Commit-Limit für die Vergleichs-API zu erhöhen oder eine zweite Commit-Seite zu holen?
Versuchen Sie es mit dem Parameter sha , zum Beispiel:
https://api.github.com/repos/junit-team/junit/commits?sha=XXX , wobei XXX der SHA des letzten zurückgegebenen Commits in der aktuellen Runde der Abfrage ist. Dann iteriere diesen Prozess, bis du die End-SHA erreichst.
Beispielpythoncode:
%Vor%Es ist relativ einfach. Hier ist ein Beispiel:
%Vor%UPDATE:
Beachten Sie, dass die nächsten URLs anders sind als die ursprünglichen ex: Anfangs-URL:
https://api.github.com/repos/pydanny/django-admin2/commits
nächste URL:
https://api.github.com/repositories/10054295/commits?top=develop&last_sha=eb204104bd40d2eaaf983a5a556e38dc9134f74e
Es ist also eine völlig neue URL-Struktur.
Ich habe versucht, das wieder zu lösen. Meine Notizen:
Die Liste "Vergleiche (oder zieht Request-Commits)" zeigt nur 250 Einträge. Für die Pull-Anforderung eins können Sie paginieren, aber Sie erhalten nur maximal 250 Commits, egal was Sie tun.
Die API für die Commit-Liste kann die gesamte Commit-Kette mit Paging bis zum Anfang des Repositorys durchlaufen.
Bei einer Pull-Anfrage ist das "Basis" -Commit nicht notwendigerweise in der Historie, die von dem Pull-Request- "Kopf" -Commit erreichbar ist. Dies ist zum Vergleich gleich, das "base_commit" ist nicht unbedingt ein Teil der Historie des aktuellen Kopfes.
Das "merge_base_commit" ist jedoch ein Teil des Verlaufs, daher ist der richtige Ansatz, mit dem Commit "head" zu beginnen und Commit-Listenabfragen zu iterieren, bis Sie das "merge_base_commit" erreichen. Für eine Pull-Anforderung bedeutet dies, dass ein Vergleich zwischen "head" und "base" des Pulls zwingend erforderlich ist.
Alternativer Ansatz besteht darin, "total_commits" zu verwenden, die von compare zurückgegeben werden, und einfach rückwärts zu durchlaufen, bis die gewünschte Anzahl an Commits erreicht ist. Dies scheint zu funktionieren, aber ich bin nicht 100% sicher, dass dies in allen Eckfällen mit Verschmelzungen und dergleichen korrekt ist.
Also, Commit List API, Seitenumbruch und "merge_base_commit" löst dieses Dilemma.
Von: Ссылка
Arbeiten mit großen Vergleichen
Die Antwort enthält einen Vergleich von bis zu 250 Commits. Wenn Sie mit einem größeren Commit-Bereich arbeiten, können Sie die Commit-Liste-API verwenden, um alle Commits im Bereich aufzuzählen.
Bei Vergleichen mit extrem großen Diffs erhalten Sie möglicherweise eine Fehlerantwort, die darauf hinweist, dass der Vergleich zu lange gedauert hat. Sie können diesen Fehler normalerweise beheben, indem Sie einen kleineren Commit-Bereich verwenden
Hier ist ein Beispiel, um ALLE Commits für eine Pull-Anfrage zu erhalten, die mit Octokit.NET ( Ссылка )
geschrieben wurde %Vor%Ich habe ursprünglich versucht, moreToGet auf true zu setzen, wenn ein Commit mit base sha gefunden wurde, aber nie in der Liste der Commits (nicht sicher warum), also nehme ich einfach mehr an, wenn der Vergleich den Grenzwert von 250 erreicht .
Tags und Links git github github-api