Reversing the arrows looks pretty silly at first, but apparently the idea is that if you start with the files that changed, you can read partial dependency graphs and start building any downstream dependencies that changed before the entire build graph is loaded. If you start from the top down, you have to load and compute the entire dependency graph up front.

This will matter for large build systems where just loading the build files takes significant time. Another way to solve it is just to make loading the build file very fast so that it's a non-issue, which is what ninja [1] does.

Apparently there's some influence: "There are many other build systems that are more user-friendly or featureful than Ninja itself. For some recommendations: the Ninja author found the tup build system influential in Ninja’s design, and thinks redo's design is quite clever." [2]

[1] http://martine.github.io/ninja/ [2] http://martine.github.io/ninja/manual.html