git rerere caches a different thing: the manual resolutions to conflicts. In this case, the conflicts would be induced by applying an old patch on top of a newly-formatted commit. However, git test fix will sidestep conflicts by reparenting the child commit, rather than applying it as a patch, so no conflicts will be produced to begin with, and the rerere mechanism won’t be triggered.
The thing that git test caches is that it won’t even switch to the commit or run the command if it detects that it already ran the command for that commit’s tree object. This is particularly useful in large patch stacks where many of the commits remain unchanged, and only a few of them need to be updated to accommodate reviewer feedback (or if it’s expensive to switch commits, such as in large repositories, or if the command is expensive).
Neat. I needed this just a few minutes ago :D
so why not
git rebase -x ...?I think git rerere handles the last point.
https://git-scm.com/docs/git-rerere
git rererecaches a different thing: the manual resolutions to conflicts. In this case, the conflicts would be induced by applying an old patch on top of a newly-formatted commit. However,git test fixwill sidestep conflicts by reparenting the child commit, rather than applying it as a patch, so no conflicts will be produced to begin with, and the rerere mechanism won’t be triggered.The thing that
git testcaches is that it won’t even switch to the commit or run the command if it detects that it already ran the command for that commit’s tree object. This is particularly useful in large patch stacks where many of the commits remain unchanged, and only a few of them need to be updated to accommodate reviewer feedback (or if it’s expensive to switch commits, such as in large repositories, or if the command is expensive).