Re: separating regression test patches from fixes, was Re: [PATCH 3/3] cherry-pick --continue: remember options
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Mar 14, 2019, 14:30 UTC
- Message-ID
- <CACsJy8DCZLNNa9zFj04kPx=f1S_5VJqqP_qTK6QYJ0fFmusymg@mail.gmail.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.1903141432000.41@tvgsbejvaqbjf.bet>
On Thu, Mar 14, 2019 at 9:10 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 5 quoted lines
> In any case, before we get better tooling to work around these issues, I > still think it makes a ton of sense to encourage proper separation of > concerns: to keep patches that introduce regression tests demonstrating a > breakage separate from patches that fix the breakage. It would certainly > help me (e.g. when staring at a range diff).
Then perhaps improve the tools now because these separate patches enter 'master' and stay in the history forever. One of the problems I have with separating tests from the actual code change is the description of the problem often stays on the test commit, which I can't see in git-log if I'm searching for the code change. And no sometimes I can't just look at the parent commit if I filter code by path (and with --full-diff)
-- Duy