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

From: Junio C Hamano <gitster@pobox.com>
Date: May 19, 2015, 21:37 UTC
Message-ID: <xmqqfv6s6ygb.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1432070690.14498.4.camel@kaarsemaker.net>

Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:

Show 12 quoted lines

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