Jeff King <p...@peff.net> writes: > My trick for checking the before/after of a patch is: > > 1. Compile git without the patch. > > 2. Apply the patch, then run the test (via ./t1234-*, which does not > want to re-build git), confirm that it fails. > > 3. Re-compile and re-run the test, confirming that it passes. > > That also works well with "rebase -i" where you stop at the patch before > to compile. > > I like it because it's simple and doesn't affect git's view (so you > can't accidentally commit the in-work-tree revert, for example). But > since there's nothing telling you what state the compiled git is in, it > can be easy to get confused.
True. It also would not work well with debuggers, but it is usually rare to need a debugger to verify the claim of a "fix" patch, so I think the above is easier to use in practice. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
