git deps
1.0.0
git-deps -это инструмент для проведения автоматического анализа зависимостей между Commits в репозитории GIT. Вот демонстрация экрана:
Я писал в блоге о git-deps и связанных с ним инструментах, а также публично рассказывал об инструменте несколько раз:
Совершенно очевидно, что два GIT Commits в пределах одного репо могут считаться «независимыми» друг от друга в определенном смысле, если они не изменяют одни и те же файлы, или если они не изменяют перекрывающиеся части одного и того же файла.
Напротив, когда коммит меняет линию, он «зависит» не только на коммите, который в последний раз менял эту линию, но и любые коммиты, которые были ответственны за предоставление окружающих линий контекста, потому что без этих предыдущих версий линии и ее контекста различие коммита может не применяться чисто (в зависимости от того, как он применяется, конечно). Таким образом, все зависимости от коммита могут быть программно выведены путем проведения Git-name в строках, которые изменяются, плюс, однако многие строки контекста имеют смысл для использования случая этого конкретного анализа зависимостей.
Следовательно, на расчет зависимости влияют параметр фактора «пузырь» (патч CF (1)), то есть количество строк контекста, которые считаются необходимыми для чистого применения различия коммита.
Как и во многих отношениях зависимостей, эти зависимости образуют ребра в DAG (направленный ациклический график), узлы которых соответствуют коммиты. Обратите внимание, что узел может зависеть только от подмножества его предков.
Важно знать, что любой график зависимостей, выведенный git-deps может быть семантически неполным; Например, это не будет автоматическим детектированием зависимостей между коммитом A, который изменяет код, и другой коммит B, который изменяет документацию или тесты, чтобы отразить изменения кода в Commit A. Поэтому git-deps не следует использовать со слепой верой. Для получения более подробной информации см. Раздел о текстовой и семантической (в) зависимости ниже.
Иногда полезно понять природу частей этого графика зависимости, так как его природа повлияет на успех или сбой операций, включая слияние, Rebase, вишня и т. Д., Пожалуйста, см. В файле USE-CASES.md файл для получения более подробной информации.
Пожалуйста, смотрите файл INSTALL.md .
Пожалуйста, смотрите файл USAGE.md .
Проницательные читатели отметят, что текстовая независимость, обнаруженная git-deps не то же самое, что семантическая / логическая независимость. Текстовая независимость означает, что изменения могут применяться в любом порядке без возникновения конфликтов, но это не является надежным показателем логической независимости.
Например, изменение функции и соответствующие изменения в тестах и/или документации для этой функции обычно существуют в разных файлах. Таким образом, если бы эти изменения были в отдельных коммитах в филиале, запуск git-deps на коммитах не обнаруживал бы никакой зависимости между ними, даже если они логически связаны, поскольку изменения в разных файлах (или даже в разных областях одних и тех же файлов) являются текстовыми.
Таким образом, в этом случае git-deps не будет вести себя именно так, как мы могли бы хотеть. А до тех пор, пока ИИ является нерешенной проблемой, очень маловероятно, что он когда -либо будет развивать совершенно надежное поведение. Значит ли это, что git-deps бесполезно? Абсолютно нет!
Во -первых, когда придерживаются лучшие практики для структурирования, изменения, которые сильно связаны с логикой, должны быть помещены в то же время. Таким образом, в приведенном выше примере изменение функции и соответствующие изменения в тестах и/или документации для этой функции должны быть в пределах одного коммита. (Хотя это не единственный действительный подход; для более продвинутого механизма группировки мета-историей см. git-dendrify .)
Во -вторых, хотя текстовая независимость не подразумевает логическую независимость, ожидается, что обратное будет более часто: логическая независимость часто подразумевает текстовую независимость (или в другом способе, текстовая зависимость часто подразумевает логическую зависимость). Таким образом, хотя для git-deps может быть не слишком редко, чтобы не обнаружить зависимость между логически связанными изменениями, должно быть более реже, что это неправильно вызывает зависимость между логически не связанными изменениями. Другими словами, его ложные негативы, как правило, будут более распространенными, чем его ложные позитивы. В результате это, вероятно, будет более полезно при определении более низкой границы зависимостей, чем верхняя граница. Сказав это, необходимы дополнительные исследования.
В -третьих, часто бесполезно позволить поискам идеального стать врагом добра - инструмент не должен быть идеальным, чтобы быть полезным; Это должно быть только лучше, чем выполнение одной и той же задачи без инструмента.
Дальнейшее обсуждение некоторых из этих пунктов можно найти в старой ветке из списка рассылки GIT.
В конечном счете, «доказательство в пудинге», так что попробуйте это и посмотрите!
Пожалуйста, смотрите файл CONTRIBUTING.md .
Пожалуйста, смотрите файл HISTORY.md .
Особая благодарность SUSE за частично спонсирование разработки этого программного обеспечения. Спасибо также всем, кто внес код, отчеты об ошибках и другие отзывы.
Выпущен в GPL версии 2, чтобы соответствовать лицензии git , но я открыт для идеи двойного лицензирования, если есть убедительная причина.
