| One trick for running tests in rebase-heavy workflows is to use the tree hash of the commit as the cache key, rather than attach metadata the commit itself. - That way, tests will be skipped when the contents of the commit are the same, while remaining insensitive to things like changes to the commit message or squashes. - But they'll re-run in situations like reordering commits (for just the reordered range, and then the cache will work again for any unchanged commits after that). I think that's important because notes will follow the commits around as they're rewritten, even if the logical contents are now different due to reordering? Amending a commit or squashing two non-adjacent commits may also have unexpected behavior if it merges the notes from both sides and fails to invalidate the cache? - This is how my `git test` command works https://github.com/arxanas/git-branchless/wiki/Command:-git-... --- I've also seen use-cases might prefer to use/add other things to the cache key: - The commit message: my most recent workflow involves embedding certain test commands in the message, so I actually do want to re-run the tests when the test commands change. - The patch ID: if you specifically don't want to re-run tests when you rebase/merge with the main branch, or otherwise reorder commits. Unfortunately, I don't have a good solution for those at present. |
Of course, if the notes mechanism didn't exist, then I could have just used a local file.. But it's nice to see the messages in the git log.
But yeah, both kinds of keys would be useful for this purpose, depending on the exact needs.