git deps
1.0.0
git-deps ist ein Tool zur automatischen Analyse von Abhängigkeiten zwischen Commits in einem Git-Repository. Hier ist eine Screencast -Demonstration:
Ich habe über git-deps und verwandte Tools gebloggt und mehrmals öffentlich über das Tool gesprochen:
Es ist ziemlich klar, dass zwei Git -Commits innerhalb eines einzelnen Repo in gewissem Sinne voneinander als "unabhängig" angesehen werden können, wenn sie nicht die gleichen Dateien ändern oder nicht überlappende Teile derselben Dateien (n) ändern.
Im Gegensatz dazu ist es, wenn ein Commit eine Linie ändert, nicht nur von dem Komitee, das diese Zeile verändert hat, sondern auch von Commits, die für die Bereitstellung der umgebenden Kontextlinien verantwortlich waren, da ohne diese früheren Versionen der Linie und ihres Kontextes das Diff der Verpflichtung möglicherweise nicht sauber gilt (je nachdem, wie es angewendet wird). Alle Abhängigkeiten eines Commits können also programmatisch abgeleitet werden, indem Git-Blame in den Zeilen ausgeführt werden. Die Commit-Änderungen sind jedoch für den Anwendungsfall dieser bestimmten Abhängigkeitsanalyse sinnvoll.
Daher wird die Abhängigkeitsberechnung durch einen "Fuzz" -Faktorparameter (CF Patch (1)) beeinflusst, dh die Anzahl der Kontextlinien, die als notwendig betrachtet werden, damit der Diff des Komitees sauber gelten.
Wie bei vielen Abhängigkeitsbeziehungen bilden diese Abhängigkeiten Kanten in einer DAG (gerichteten acyclischen Graphen), deren Knoten den Commits entsprechen. Beachten Sie, dass ein Knoten nur von einer Untergruppe seiner Vorfahren abhängen kann.
Es ist wichtig zu wissen, dass jedes Abhängigkeitsgraphen, das von git-deps abgeleitet wird, semantisch unvollständig sein kann. Zum Beispiel würde es keine Abhängigkeiten zwischen einem Commit A automatisch erkennen, das den Code und ein anderes Commit B ändert, das Dokumentation oder Tests ändert, um die Codeänderungen im Commit A zu widerspiegeln. Daher sollten git-deps nicht mit blindem Glauben verwendet werden. Weitere Informationen finden Sie im Abschnitt zu Textual vs. Semantic (in) Abhängigkeit unten.
Manchmal ist es nützlich, die Art von Teilen dieses Abhängigkeitsdiagramms zu USE-CASES.md , da sich seine Natur auf den Erfolg oder Misserfolg von Operationen wie Merge, Rebase, Cherry-Pick usw. auswirkt
Bitte beachten Sie die Datei INSTALL.md .
Bitte beachten Sie die Datei USAGE.md .
Kluge Leser werden feststellen, dass die von git-deps festgestellte textuelle Unabhängigkeit nicht mit der semantischen / logischen Unabhängigkeit entspricht. Textunabhängig bedeutet, dass die Änderungen in beliebiger Reihenfolge ohne Konflikte angewendet werden können. Dies ist jedoch kein zuverlässiger Indikator für die logische Unabhängigkeit.
Zum Beispiel würde eine Änderung einer Funktion und entsprechende Änderungen an den Tests und/oder Dokumentationen für diese Funktion in verschiedenen Dateien in der Regel vorhanden. Wenn diese Änderungen in einer Reihe in einer Filiale wären, würde das Ausführen git-deps in den Commits keine Abhängigkeit zwischen ihnen erkennen, obwohl sie logisch verwandt sind, da Änderungen in verschiedenen Dateien (oder sogar in verschiedenen Bereichen derselben Dateien) textuell unabhängig sind.
In diesem Fall würden sich git-deps also nicht genau verhalten, wie wir es wollen. Und solange KI ein ungelöstes Problem ist, ist es sehr unwahrscheinlich, dass sie jemals ein völlig zuverlässiges Verhalten entwickeln wird. Bedeutet das also, dass git-deps nutzlos ist? Absolut nicht!
Erstens sollten Änderungen, die stark logisch verwandt sind, ohnehin, wenn Best Practices for Commit -Strukturierung eingehalten werden. Im obigen Beispiel sollte eine Änderung einer Funktion und entsprechenden Änderungen der Tests und/oder der Dokumentation für diese Funktion innerhalb eines einzelnen Commits liegen. (Obwohl dies nicht der einzige gültige Ansatz ist; für einen fortgeschritteneren Mechanismus zur Gruppierung von Meta-Geschichten siehe git-dendrify .)
Zweitens bedeutet die Unabhängigkeit von textuellen Unabhängigkeit, aber erwartet wird, dass der Gegenteil häufiger wahr ist: Die logische Unabhängigkeit impliziert häufig die textuelle Unabhängigkeit (oder eine andere Weise, die textliche Abhängigkeit impliziert häufig logische Abhängigkeit). Obwohl es möglicherweise nicht zu ungewöhnlich ist, dass git-deps die Abhängigkeit zwischen logisch verwandten Änderungen nicht erkennen, sollte es seltener sein, dass es eine Abhängigkeit zwischen logisch nicht verwandten Veränderungen fälschlicherweise stärkt. Mit anderen Worten, es wird allgemein erwartet, dass seine falschen Negative häufiger als seine falsch positiven Aspekte sind. Infolgedessen ist es wahrscheinlich nützlicher, eine untere Grenze von Abhängigkeiten zu bestimmen als eine Obergrenze. Trotzdem sind hierfür mehr Forschung erforderlich.
Drittens ist es oft nicht hilfreich, die Suche nach dem perfekten Werden zum Feind des Guten zu ermöglichen - ein Werkzeug muss nicht perfekt sein, um nützlich zu sein. Es muss nur besser sein, als dieselbe Aufgabe ohne das Tool auszuführen.
Weitere Diskussionen über einige dieser Punkte finden Sie in einem alten Thread aus der Git -Mailingliste.
Letztendlich "Der Beweis ist im Pudding", probieren Sie es aus und sehen Sie es aus!
Weitere Informationen finden Sie in der Datei CONTRIBUTING.md .
Bitte beachten Sie die Datei HISTORY.md .
Besonderer Dank geht an SUSE, dass sie die Entwicklung dieser Software teilweise gesponsert hat. Vielen Dank auch an alle, die Code, Fehlerberichte und andere Feedbacks beigetragen haben.
Veröffentlicht unter GPL Version 2, um mit git Lizenz übereinzustimmen, aber ich bin offen für die Idee der Dual-Lizenzierung, wenn es einen überzeugenden Grund gibt.
