From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Giuffrida <michaelpg@chromium.org>, git@vger.kernel.org
Subject: Re: [BUG] add_again() off-by-one error in custom format
Date: Tue, 13 Jun 2017 22:29:01 +0200 [thread overview]
Message-ID: <99d19e5a-9f79-9c1e-3a23-7b2437b04ce9@web.de> (raw)
In-Reply-To: <xmqqtw3j68rc.fsf@gitster.mtv.corp.google.com>
Am 13.06.2017 um 20:29 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> Indeed, a very nice bug report!
>>
>>> I think the call to format_commit_one() needs to be taught to pass
>>> 'magic' through, and then add_again() mechanism needs to be told not
>>> to cache when magic is in effect, or something like that.
>>>
>>> Perhaps something along this line...?
>>>
>>> pretty.c | 64 ++++++++++++++++++++++++++++++++++++++--------------------------
>>> 1 file changed, 38 insertions(+), 26 deletions(-)
>>
>> That looks quite big. You even invent a way to classify magic.
>
> Hmph, by "a way to classify", do you mean the enum? That thing was
> there from before, just moved.
Oh, yes, sorry. I didn't even get that far into the patch. (I'll
better go to bed after hitting send..)
> Also I think we do not have to change add_again() at all, because
> chunk->off tolerates being given a garbage value as long as
> chunk->len stays 0, and add_again() does not change chunk->len at
> all.
>
> Which cuts the diffstat down to
>
> pretty.c | 40 +++++++++++++++++++++++++---------------
> 1 file changed, 25 insertions(+), 15 deletions(-)
>
>> Does the caching feature justify the added complexity?
>
> That's a good question. I thought about your second alternative
> while adding the "don't cache" thing, but if we can measure and find
> out that we are not gaining much from caching, certainly that sounds
> much simpler.
The difference is about the same as the one between:
$ time git log --format="" >/dev/null
real 0m0.463s
user 0m0.448s
sys 0m0.012s
and:
$ time git log --format="%h" >/dev/null
real 0m1.062s
user 0m0.636s
sys 0m0.416s
With caching duplicates are basically free and without it short
hashes have to be looked up again. Other placeholders may reduce
the relative slowdown, depending on how expensive they are.
Forgot a third option, probably because it's not a particularly good
idea: Replacing the caching in pretty.c with a short static cache in
find_unique_abbrev_r().
René
next prev parent reply other threads:[~2017-06-13 20:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 3:13 [BUG] add_again() off-by-one error in custom format Michael Giuffrida
2017-06-12 22:49 ` Junio C Hamano
2017-06-13 18:09 ` René Scharfe
2017-06-13 18:29 ` Junio C Hamano
2017-06-13 20:29 ` René Scharfe [this message]
2017-06-13 21:20 ` Junio C Hamano
2017-06-14 18:24 ` René Scharfe
2017-06-15 5:56 ` Jeff King
2017-06-15 11:33 ` René Scharfe
2017-06-15 13:25 ` Jeff King
2017-06-18 10:58 ` René Scharfe
2017-06-18 11:49 ` Jeff King
2017-06-18 12:59 ` René Scharfe
2017-06-18 13:56 ` Jeff King
2017-06-22 18:19 ` René Scharfe
2017-06-22 23:15 ` Jeff King
2017-06-18 10:58 ` René Scharfe
2017-06-18 11:50 ` Jeff King
2017-06-19 4:46 ` Junio C Hamano
2017-06-22 18:19 ` [PATCH] sha1_name: cache readdir(3) results in find_short_object_filename() René Scharfe
2017-06-22 23:10 ` Jeff King
2017-06-24 12:12 ` René Scharfe
2017-06-24 12:14 ` Jeff King
2017-06-24 12:12 ` René Scharfe
2017-06-24 12:20 ` Jeff King
2017-06-24 14:09 ` René Scharfe
2017-06-24 14:12 ` Jeff King
2017-06-15 18:37 ` [BUG] add_again() off-by-one error in custom format Junio C Hamano
2017-06-13 22:24 ` SZEDER Gábor
2017-06-14 17:34 ` René Scharfe
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=99d19e5a-9f79-9c1e-3a23-7b2437b04ce9@web.de \
--to=l.s.r@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=michaelpg@chromium.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).