1. 23
    1. 2

      Neat. I needed this just a few minutes ago :D

    2. 2

      so why not git rebase -x ...?

      1. 5
        • It can’t run in parallel
        • It produces spurious merge conflicts for things like formatter changes
        • It can’t run if the working copy is dirty
        • It only runs on linear sequences of commits
        • It won’t cache already-processed commits
        1. 2

          I think git rerere handles the last point.


          1. 3

            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).