Dennis Kaarsemaker <dennis@xxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html