Mostyn and jl and I talked about this the other day and it seems it would be most likely to work well if using the output from git status, though the performance of that might be not good enough. Especially if we do as today, and build one jumbo file at a time (that is a lot of git status calls).

The old minimake depended on timestamps and a git hook which is a bit too cumbersome and wouldn't scale well with a project the size of Chromium.

One case that this will miss is when a header file is modified. If modifying that header file causes many .cc files to be recompiled then jumbo is probably a net win but if the header is included by just a single .cc file then jumbo will probably hurt rebuild times. That said, I'm not sure trying to handle the header-file case is worthwhile.

"git status" is slow enough on Windows to make me hesitant to have this run automatically. And, since v8 is jumbified we'd really need to run "git status" on that repo as well.

On the other hand, making it easier to exclude the files being edited could be pretty darned useful. Maybe have a script to run the process on demand? That is, something like this:

    python third_party\depot_tools\update_jumbo_exclude.py out\debug

I haven't looked into how the jumbo file excluding works but it is important that it not perturb any other jumbo file sets. That is, the boundaries between sets must stay static or else extra compilation will be required when the exclusions change.

A minimal change would be to have jumbo.gni prepare a "recently_modified_files_jumbo.cc which is normally empty but where merge_files_for_jumbo.py inserts recently changed files. They would still not be compiled individually and it could cause a build time regression from all the empty files, but it could be done without changing the structure of the current jumbo implementation.