Subject: Re: [PATCH v2] pull: handle --log=<n>

From: Junio C Hamano <[email-masked]>
Date: Tue, 19 May 2015 14:37:24 -0700

Dennis Kaarsemaker <[email-masked]> writes:

> I took a stab at this, adding a --tag option to test_commit and adding
> the option to the test_commit calls that need it (or removing tests'
> reliance on these tags where appropriate, or removing tests' workarounds
> for dealing with these tags when they don't want them), and the result
> is 59 files changed, 280 insertions(+), 281 deletions(-)
>
> A test run on master with GIT_TEST_LONG set causes 1138 calls to
> test_commit on my system, of which 255 now use the --tag option
> (measured with a really crude hack that INCR's some keys in redis at
> appropriate points in test_commit).
>
> Is this interesting enough to turn into a proper patch series?

Wow.

A proper patch series would probably be

 [1/N]   Teach "test_commit --tag" and replace existing "test_commit"
         with "test_commit --tag"

 [2-N/N] For all the test scripts, analyse and judge if they are
         better off with the auto-generated tags (i.e. no change wrt
         the result of 1/N) or tags that are created by the script
         at strategic places only as needed, and convert those that
         are better read without "test_commit --tag".

[1/N] would be mechanical and easy, but justifying the change in the
remainder would be a lot of work and reviewing would be, too, and
would require a good taste.

Perhaps if we see two sample patches to see how it looks like, would
that help us decide?

That is, the mechanical [1/N] and [2/N] for one of the test script
that can do without --tag, and a sample "do not apply" patch to show
"if we change 'test_commit --tag' to 'test_commit', the script t1234
needs this many manual tagging by the caller, and it is not worth
doing"?  I dunno.

Thanks.