All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>,
	Paul Tan <pyokagan@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Stefan Beller <sbeller@google.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCH v2] pull: handle --log=<n>
Date: Tue, 19 May 2015 23:49:27 +0200	[thread overview]
Message-ID: <1432072167.14498.12.camel@kaarsemaker.net> (raw)
In-Reply-To: <xmqqfv6s6ygb.fsf@gitster.dls.corp.google.com>

On di, 2015-05-19 at 14:37 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker <dennis@kaarsemaker.net> 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.

I've actually done it differently while implementing:

1) Make test_commit recognize --tags and stop creating tags unless
   specified
2) while ! prove --state=save,failed {
       Find and fix tests that now need --tags
   }

For the actual patch series I'll add -p the changes slightly
differently:

1/N: Make test_commit recognize a --tags parameter but not change
behaviour.
2/N - N-1/N: Add --tags where necesary (or other fixes as appropriate)
N/N: Only write tags when --tags is passed to test_commit.

That way 'make test' will pass at every step.

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

I'll just send an entire patch series. It's not that much more work.

-- 
Dennis Kaarsemaker
www.kaarsemaker.net

  reply	other threads:[~2015-05-19 21:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-18 13:39 [PATCH v2] pull: handle --log=<n> Paul Tan
2015-05-18 14:53 ` Johannes Schindelin
2015-05-18 18:18   ` Junio C Hamano
2015-05-19 13:35     ` Johannes Schindelin
2015-05-19 13:57       ` Junio C Hamano
2015-05-19 21:24         ` Dennis Kaarsemaker
2015-05-19 21:33           ` Stefan Beller
2015-05-19 21:43             ` Dennis Kaarsemaker
2015-05-19 21:37           ` Junio C Hamano
2015-05-19 21:49             ` Dennis Kaarsemaker [this message]
2015-05-19 22:10               ` Junio C Hamano
2015-05-19 22:30                 ` Dennis Kaarsemaker
2015-05-19 23:14                   ` Junio C Hamano
2015-05-20  2:19                     ` Junio C Hamano
2015-05-20  8:11                       ` Dennis Kaarsemaker
2015-05-20  5:10             ` Junio C Hamano
2015-05-20  8:13               ` Dennis Kaarsemaker
2015-05-21 10:36   ` [PATCH v3] " Paul Tan
2015-05-21 21:24     ` Junio C Hamano
2015-05-22 13:29       ` Paul Tan
2015-05-18 15:15 ` [PATCH v2] " Paul Tan
2015-05-18 15:26   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1432072167.14498.12.camel@kaarsemaker.net \
    --to=dennis@kaarsemaker.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=pyokagan@gmail.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.