From: Jeff King <peff@peff.net>
To: Axel Bonnet <axel.bonnet@ensimag.imag.fr>
Cc: git@vger.kernel.org,
"Diane Gasselin" <diane.gasselin@ensimag.imag.fr>,
"Clément Poulain" <clement.poulain@ensimag.imag.fr>
Subject: Re: [RFC/PATCH 3/4] textconv: support for blame
Date: Sun, 6 Jun 2010 17:51:59 -0400 [thread overview]
Message-ID: <20100606215159.GA6993@coredump.intra.peff.net> (raw)
In-Reply-To: <1275562038-7468-4-git-send-email-axel.bonnet@ensimag.imag.fr>
On Thu, Jun 03, 2010 at 12:47:17PM +0200, Axel Bonnet wrote:
> /*
> + * Prepare diff_filespec and convert it using diff textconv API
> + * if the textconv driver exists.
> + * Return 1 if the conversion succeeds, 0 otherwise.
> + */
> +static int textconv_object(const char *path,
> + const unsigned char *sha1,
> + unsigned short mode,
> + struct strbuf *buf)
> +{
> + struct diff_filespec *df;
> +
> + df = alloc_filespec(path);
> + fill_filespec(df, sha1, mode);
> + get_textconv(df);
> +
> + if (!df->driver|| !df->driver->textconv) {
> + free_filespec(df);
> + return 0;
> + }
df->driver is always non-NULL these days, isn't it? Also, why not just
use the return value of get_textconv, which does handles this
conditional for you already (and avoids peeking directly at df->driver,
which was what get_textconv was meant to abstract). I.e.:
struct userdiff_driver *textconv;
...
textconv = get_textconv(df);
if (!textconv)
... free and return ...
> + buf->len = fill_textconv(df->driver, df, &buf->buf);
> + buf->alloc = 1;
> + free_filespec(df);
> + return 1;
Shoving the allocated buffer into a strbuf really feels like an abuse of
strbuf. I don't think there is any bug here (the original buffer
actually comes from a strbuf, and by setting alloc to 1, you indicate
that any further appending would need to realloc), but it just seems
like violating the boundary of the strbuf API.
And it isn't really necessary because:
> + if (DIFF_OPT_TST(&opt, ALLOW_TEXTCONV) &&
> + textconv_object(o->path, o->blob_sha1, mode, &buf))
> + file->ptr = strbuf_detach(&buf, (size_t *) &file->size);
You just end up pulling it out into an mmfile_t, anyway. So why involve
strbuf at all?
> static void fill_origin_blob(struct diff_options opt,
> struct origin *o, mmfile_t *file)
> {
> + unsigned mode;
> +
> if (!o->file.ptr) {
> + struct strbuf buf = STRBUF_INIT;
> enum object_type type;
> num_read_blob++;
> - file->ptr = read_sha1_file(o->blob_sha1, &type,
> - (unsigned long *)(&(file->size)));
> +
> + get_tree_entry(o->commit->object.sha1,
> + o->path,
> + o->blob_sha1, &mode);
> + if (DIFF_OPT_TST(&opt, ALLOW_TEXTCONV) &&
> + textconv_object(o->path, o->blob_sha1, mode, &buf))
> + file->ptr = strbuf_detach(&buf, (size_t *) &file->size);
> + else
> + file->ptr = read_sha1_file(o->blob_sha1, &type,
> + (unsigned long *)(&(file->size)));
> + strbuf_release(&buf);
I don't understand why there's a get_tree_entry call here. Don't we
already have the path and blob_sha1 fields? Is the mode actually
relevant (i.e., can we just fake it for the purposes of the
diff_filespec we will create)?
Even if we do need the get_tree_entry call, shouldn't it happen only if
we are allowing textconv, so non-textconv users don't pay for the call?
> @@ -2249,8 +2291,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> int cmd_is_annotate = !strcmp(argv[0], "annotate");
>
> git_config(git_blame_config, NULL);
> + git_config(git_diff_ui_config, NULL);
Like Junio, I am worried about the unintended consequences of
git_diff_ui_config. The userdiff drivers are parsed as part of
git_diff_basic_config, and you should use that.
Also, you are better to just add the call to git_blame_config (either
git_diff_basic_config, or looking directly to userdiff_config) instead
of calling git_config again, which will avoid parsing the config files
twice.
-Peff
next prev parent reply other threads:[~2010-06-06 21:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-03 10:47 [RFC/PATCH 0/4] textconv support for blame Axel Bonnet
2010-06-03 10:47 ` [RFC/PATCH 1/4] textconv: make the API public Axel Bonnet
2010-06-03 10:47 ` [RFC/PATCH 2/4] textconv: make diff_options accessible from blame Axel Bonnet
2010-06-03 10:47 ` [RFC/PATCH 3/4] textconv: support for blame Axel Bonnet
2010-06-03 10:47 ` [RFC/PATCH 4/4] t/t8006: test textconv " Axel Bonnet
2010-06-03 15:44 ` Johannes Sixt
2010-06-04 8:55 ` Diane Gasselin
2010-06-04 9:45 ` Matthieu Moy
2010-06-04 8:49 ` Matthieu Moy
2010-06-04 6:00 ` [RFC/PATCH 3/4] textconv: " Junio C Hamano
2010-06-04 10:34 ` Diane Gasselin
2010-06-06 21:51 ` Jeff King [this message]
2010-06-04 5:48 ` [RFC/PATCH 2/4] textconv: make diff_options accessible from blame Junio C Hamano
2010-06-04 7:59 ` Matthieu Moy
2010-06-04 10:21 ` bonneta
2010-06-04 17:23 ` Matthieu Moy
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=20100606215159.GA6993@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=axel.bonnet@ensimag.imag.fr \
--cc=clement.poulain@ensimag.imag.fr \
--cc=diane.gasselin@ensimag.imag.fr \
--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).