git deps
1.0.0
git-deps est un outil pour effectuer une analyse automatique des dépendances entre les validations dans un référentiel GIT. Voici une démonstration de screencast:
J'ai blogué sur git-deps et les outils connexes, et j'ai également parlé à plusieurs reprises de l'outil:
Il est assez clair que deux Git s'engagent dans un seul dépôt peuvent être considérés comme "indépendants" les uns des autres dans un certain sens, s'ils ne modifient pas les mêmes fichiers, ou s'ils ne changent pas de parties qui se chevauchent du même fichier (s).
En revanche, lorsqu'un engagement modifie une ligne, il est "dépendant" non seulement de l'engagement qui a changé pour la dernière fois cette ligne, mais aussi de tous les engagements qui étaient responsables de la fourniture des lignes de contexte environnantes, car sans les versions précédentes de la ligne et de son contexte, le diff. Ainsi, toutes les dépendances d'un engagement peuvent être déduites par programme en exécutant Git-Blame sur les lignes, les changements de validation, plus de nombreuses lignes de contexte ont du sens pour le cas d'utilisation de cette analyse de dépendance particulière.
Par conséquent, le calcul de la dépendance est affecté par un paramètre de facteur "fuzz" (CF Patch (1)), c'est-à-dire le nombre de lignes de contexte qui sont considérées comme nécessaires pour que le Diff de la validation s'applique proprement.
Comme pour de nombreuses relations de dépendance, ces dépendances forment des bords dans un DAG (graphique acyclique dirigé) dont les nœuds correspondent aux validations. Notez qu'un nœud ne peut dépendre qu'un sous-ensemble de ses ancêtres.
Il est important de savoir que tout graphique de dépendance déduit par git-deps peut être sémantiquement incomplet; Par exemple, il ne serait pas de dépendances à détecter automatiquement entre un engagement A qui change de code et un autre engagement b qui change de documentation ou de tests pour refléter les changements de code dans le commit A. Par conséquent, git-deps ne doit pas être utilisé avec une foi aveugle. Pour plus de détails, consultez la section sur la dépendance textuelle vs sémantique (IN) ci-dessous.
Parfois, il est utile de comprendre la nature de certaines parties de ce graphique de dépendance, car sa nature aura un impact sur le succès ou l'échec des opérations, notamment la fusion, la rébase, le cick-pick, etc. Veuillez consulter le fichier USE-CASES.md pour plus de détails.
Veuillez consulter le fichier INSTALL.md .
Veuillez consulter le fichier USAGE.md .
Les lecteurs astucieux noteront que l'indépendance textuelle telle que détectée par git-deps n'est pas la même chose que l'indépendance sémantique / logique. L'indépendance textuelle signifie que les modifications peuvent être appliquées dans n'importe quel ordre sans engager des conflits, mais ce n'est pas un indicateur fiable de l'indépendance logique.
Par exemple, une modification d'une fonction et des modifications correspondantes des tests et / ou de la documentation de cette fonction existeraient généralement dans différents fichiers. Donc, si ces modifications se trouvaient dans des validations séparées dans une branche, l'exécution git-deps sur les validations ne détecterait aucune dépendance entre eux, même si elles sont logiquement liées, car les changements dans différents fichiers (ou même dans différents domaines des mêmes fichiers) sont textuellement indépendants.
Donc, dans ce cas, git-deps ne se comporterait pas exactement comme nous pourrions vouloir. Et tant que l'IA est un problème non résolu, il est très peu probable qu'il développe un comportement totalement fiable. Cela signifie-t-il donc que git-deps est inutile? Absolument pas!
Premièrement, lorsque les meilleures pratiques de structuration de validation sont respectées, les changements qui sont fortement liés logiquement devraient être placés dans le même engagement de toute façon. Ainsi, dans l'exemple ci-dessus, une modification de une fonction et des modifications correspondantes des tests et / ou de la documentation de cette fonction doivent tous être dans un seul engagement. (Bien que ce ne soit pas la seule approche valide; pour un mécanisme de regroupement de méta-histoires plus avancé, voir git-dendrify .)
Deuxièmement, alors que l'indépendance textuelle n'implique pas l'indépendance logique, l'inverse devrait être plus communément vrai: l'indépendance logique implique souvent l'indépendance textuelle (ou énoncée d'une autre manière, la dépendance textuelle implique souvent une dépendance logique). Ainsi, bien qu'il ne soit pas trop rare pour git-deps de ne pas détecter la dépendance entre les changements logiquement liés, il devrait être plus rare qu'il dépeint à tort une dépendance entre les changements logiquement non liés. En d'autres termes, ses faux négatifs devraient généralement être plus courants que ses faux positifs. En conséquence, il est susceptible d'être plus utile pour déterminer une limite inférieure sur les dépendances qu'une limite supérieure. Cela dit, plus de recherches sont nécessaires à ce sujet.
Troisièmement, il est souvent inutile de permettre à la quête du parfait de devenir l'ennemi du bien - un outil ne doit pas être parfait pour être utile; Il ne doit être meilleur que d'effectuer la même tâche sans l'outil.
Une discussion plus approfondie sur certains de ces points peut être trouvée dans un ancien fil de la liste de diffusion GIT.
En fin de compte, "la preuve est dans le pudding", alors essayez-le et voyez!
Veuillez consulter le fichier CONTRIBUTING.md .
Veuillez consulter le fichier HISTORY.md .
Un merci spécial à SUSE pour avoir parrainé partiellement le développement de ce logiciel. Merci également à tous ceux qui ont contribué du code, des rapports de bogues et d'autres commentaires.
Sorti sous la version 2 de GPL afin d'être conforme à la licence de git , mais je suis ouvert à l'idée de double licence en cas de raison convaincante.
