Re: separating regression test patches from fixes, was Re: [PATCH 3/3] cherry-pick --continue: remember options

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 18, 2019, 08:07 UTC
Message-ID: <xmqqtvg0zjva.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CACsJy8DCZLNNa9zFj04kPx=f1S_5VJqqP_qTK6QYJ0fFmusymg@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

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

In the message you are reponding to, Dscho made it sound as if I am reviewing only from my MUA, but most of my reviews are done after the patches are tentatively applied (it is a separate issue if the result is found worth keeping and merged to 'pu'), so our workflows are not so different. It is not like "must have them separate" is the need shared among those who prefer to review in-tree. I do not want a logically single patch split into two.

And I find your "find the other half" of a pair of patch that is artificially split into two a real problem for me, too. If you split a single patch into two, depending on which half you find first, finding the other half is either trivial (as you can just follow the parent pointer to $THAT_THING^) or hard (you'd need to have something that binds everything together, like 'pu', and grep for "git log ..pu" trying to find what its most relevant child is).