Proposed (and tested) workflow:

(Edit: see below for more recent workflow.)

# save pre-change ASTs
make -j build-all-asts
find . -name '*.ml.ast' | xargs git add

# do your parser changes
# ...
make promote-menhir

# compare new ASTs
make -j build-all-asts
git diff # shows any .ml.ast difference

# remove AST files
find . -name '*.ml.ast' | xargs git reset HEAD
find . -name '*.ml.ast' | xargs rm

Should we be checking in the old .ast file into the repository and having a formal test? Then it would be easy to make changes. If you meant for the .ast file to change, you would of course modify it as part of your updates.

I would rather not, because source files change frequently and I believe this would cause too much churn to be comfortable. (In the world of git, reviewing and managing the list of changing files are common operations; doubling the number of changed files would have a large usability cost.)

I decided to extend build-all-asts to also the .mli files in the compiler distribution, and discovered that -stop-after parsing is not currently taken into account when processing .mli files; this is fixed by #2032.

@nojb: I applied your comments, added .mli file testing, and a list-all-asts target to make manual scripting easier for users.

Sounds cool, very useful!

With the list-all-asts rule, the new workflow looks as follows:

# save pre-change ASTs
make -j build-all-asts
make list-all-asts | xargs git add

# do your parser changes
# ...
make promote-menhir

# compare new ASTs
make -j build-all-asts
git diff # shows any .ml.ast difference

# remove AST files from the index
make list-all-asts | xargs git reset HEAD

# remove the files (if no further parser change planned)
make list-all-asts | xargs rm

Thanks! Merged.