Tools like this are also useful if you need to cherry pick a patch onto a release branch and want to know potential dependencies:

  ↑ newer
  D* fixes bug in crypto.py
  C
  B* rewrites crypto.sh in Python
  A
  0  last month’s release
  ↓ older

You get false positives and false negatives: if B fixed a comment typo for example it’s not really a dependency, and if C updated a module imported in the new code in D you’d miss it. (For the latter, in Python at least, you can build an import DAG with ast. It’s a really useful module and is incredibly fast!)

So I would say the author’s tool is really multiple tools:

1/ build a dependency graph between commits based on file changes in a range of commits;

2/ automate the reordering and squashing of dependent commits on a private dev branch;

3/ automate cherry-picking commits onto a proposed release branch (which is basically the same as git-rebase -i); and

4/ build a dependency graph based on external analysis (in my example, Python module imports) rather than / as well as file changes.

Their use case is (1) and (2), (3) is a similar but slightly different tool to (2), and (4) is a language specific nicety that goes beyond the scope of simple git changes for, arguably, diminished returns.