Re: [PATCH v2 00/33] Yet more preparation for reference backends

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2016, 16:10 UTC
Message-ID: <xmqqfutngsud.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160512075555.GC10922@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

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