From: "\"Peter Valdemar Mørch (Lists)\"" <4ux6as402@sneakemail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] Teach git log --check to return an appropriate error code
Date: Sun, 10 Aug 2008 19:05:40 +0200 [thread overview]
Message-ID: <489F1FE4.6090400@sneakemail.com> (raw)
In-Reply-To: <7v8wv66l8d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano gitster-at-pobox.com |Lists| wrote:
> 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.
Hmm... I've looked at the code... The while loop that iterates through
the revisions is in cmd_log_walk(), which calls log_tree_commit(), which
in turn calls log_tree_diff().
I'm thinking that cmd_log_walk() is where one "would want" to change
rev->diffopt / opt->diffopt in the future, and hence I suggest to put
the comment there - given my limited understanding of connecting tissue.
Something like:
/* For --check, the exit code is based on CHECK_FAILED
being accumulated in rev->diffopt, so be careful to retain
that state information if replacing rev->diffopt in this
loop */
That would also be 10-15 lines above the patch I posted earlier, so the
connection with retrieving the error code would be visible 15 lines below.
Would such a comment in that place constiture and acceptable patch? I've
tried to follow Dscho's write up and contribute a patch, even though
git-log's exit code was never my itch to begin with, because I'm exited
to contribute.
> 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.
I'm hoping that this is meant as "aside from this current patch, one
interesting option..." or do you mean "in order for this patch to be
accepted, I suggest this to be added ..." ?
This is growing. I originally suggested a patch to documentation to make
it match the code, but took on Dscho's invitation to contribute a code
patch instead. But given that this patch, although working, still isn't
good enough and the new proposals : the new option above and --exit-code
proposal elsewhere in this thread, I'm getting a little discouraged. I'm
not saying you meant it that way.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
next prev parent reply other threads:[~2008-08-10 17:06 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
2008-08-10 17:05 ` "Peter Valdemar Mørch (Lists)" [this message]
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=489F1FE4.6090400@sneakemail.com \
--to=4ux6as402@sneakemail.com \
--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).