From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 12 May 2016 16:10:34 GMT
Subject: Re: [PATCH v2 00/33] Yet more preparation for reference backends
Message-ID: <xmqqfutngsud.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160512075555.GC10922@sigill.intra.peff.net>

Jeff King <peff@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.