git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Peter Valdemar Mørch" <4ux6as402@sneakemail.com>, git@vger.kernel.org
Subject: Re: [PATCH] Teach git log --check to return an appropriate error code
Date: Sat, 09 Aug 2008 12:29:06 -0700	[thread overview]
Message-ID: <7v8wv66l8d.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.DEB.1.00.0808091404230.24820@pacific.mpi-cbg.de.mpi-cbg.de> (Johannes Schindelin's message of "Sat, 9 Aug 2008 14:05:01 +0200 (CEST)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sat, 9 Aug 2008, Peter Valdemar Mørch wrote:
>
>> 	Whether or not a check fails is stored in the
>> 	DIFF_OPT_CHECK_FAILED field of flags in struct diff_options.
>> 	This flag-field is only set (diff.c:1644), never cleared.
>
> That is a side effect.  How wise is it to rely on that?

Hmm, good point.

The bit will never be cleared during a single diff run by design, because
it needs to be cumulative in order to check a patch that describes changes
to multiple paths --- iow, the API sequence is (1) the caller to the diff
machinery resets the bit to zero and then (2) the caller exercises the
diff machinery and expects the machinery to set the bit if even a single
failure is detected, or leaves it unset if there is none.

So unless you (log_tree_diff(), the caller of diff machinery), decide to
explicitly reset the bit (or decide to use a freshly allocated and
initialized diff_options for each commit it feeds diff_tree_sha1()), the
assumption would hold.  We need to see how plausible it would be for us to
break that assumption in the future.

Future versions of log_tree_diff() may want to tweak opt->diffopt per
commit, when we have options for "use larger -U<lines> value after hitting
this commit", or "use this pathspec to limit the diff output after hitting
this commit", for example.  But even in these cases, I think it is
implausible to start from a freshly initialized diff_options structure.
The code most likely would start from the copy of what was in use and
update only the necessary fields, without disturbing the state variables.

So I think you are worried a bit too much in this case, even though it is
a valid concern in principle.  It might warrant a comment somewhere inside
log_tree_diff() to tell people not to re-initialize opt->diffopt per
commit without thinking, though.

One interesting option that might be interesting to add to the log family
would be to show only commits that fail the checkdiff tests.  I suspect
necessary change for doing so would go to log_tree_diff() codepath.

  reply	other threads:[~2008-08-09 19:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  9:39 git diff/log --check exitcode and PAGER environment variable "Peter Valdemar Mørch (Lists)"
2008-08-08  9:44 ` Junio C Hamano
2008-08-08 10:04   ` "Peter Valdemar Mørch (Lists)"
2008-08-08 10:15   ` Re* " Junio C Hamano
2008-08-08 11:02     ` "Peter Valdemar Mørch (Lists)"
2008-08-08 11:23       ` Johannes Schindelin
2008-08-08 20:40         ` Junio C Hamano
2008-08-09  6:57         ` [PATCH] Teach git log --check to return an appropriate error code Peter Valdemar Mørch
2008-08-09 12:05           ` Johannes Schindelin
2008-08-09 19:29             ` Junio C Hamano [this message]
2008-08-10 17:05               ` "Peter Valdemar Mørch (Lists)"
2008-08-10 18:40                 ` Junio C Hamano
2008-08-09 18:58           ` Junio C Hamano
2008-08-11  6:46           ` PATCH v2 0/2 Trying patch again Peter Valdemar Mørch
2008-08-11  6:46             ` [PATCH v2 1/2] Teach git log --check to return an appropriate exit code Peter Valdemar Mørch
2008-08-11  6:46               ` [PATCH v2 2/2] Teach git log --exit-code " Peter Valdemar Mørch
2008-08-08 13:17   ` git diff/log --check exitcode and PAGER environment variable Jeff King
2008-08-08 13:19     ` Jeff King

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=7v8wv66l8d.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=4ux6as402@sneakemail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).