git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Junio C Hamano via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Han-Wen Nienhuys <hanwenn@gmail.com>
Subject: Re: [PATCH v2 4/4] Cleanse reflog messages in the refs.c layer
Date: Fri, 10 Jul 2020 14:06:07 -0700	[thread overview]
Message-ID: <xmqqtuyfrsg0.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <6ca5b99c8d7af1a3f35b3a7d25db284c879a2f10.1594401593.git.gitgitgadget@gmail.com> (Junio C. Hamano via GitGitGadget's message of "Fri, 10 Jul 2020 17:19:53 +0000")

"Junio C Hamano via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Currently, the cleansing of the reflog message is done by the files
> backend, before the log is written out.  This is sufficient with the
> current code, as that is the only backend that writes reflogs.  But
> new backends can be added that write reflogs, and we'd want the
> resulting log message we would read out of "log -g" the same no
> matter what backend is used.

I _think_ there is no correctness impact, but this slightly changes
the semantics.  We used to take whatever random string from the
caller and at the lowest layer of the files backend, i.e.

>  	strbuf_addf(&sb, "%s %s %s", oid_to_hex(old_oid), oid_to_hex(new_oid), committer);
>  	if (msg && *msg)
> -		copy_reflog_msg(&sb, msg);
> +		strbuf_addstr(&sb, msg);

cleansed and added the message to strbuf.

With the updated code, normalize_reflog_message() is defined like so

> +static char *normalize_reflog_message(const char *msg)
> +{
> +	struct strbuf sb = STRBUF_INIT;
> +
> +	if (msg && *msg)
> +		copy_reflog_msg(&sb, msg);
> +	return strbuf_detach(&sb, NULL);
> +}

to always return a non-NULL but an empty string, even if the caller
gave us a NULL pointer.  We always pass a non-NULL string around,
and the updated low-level code avoids calling strbuf_addstr()
because msg is not NULL, but *msg is '\0'.

We _might_ be able to optimize by tweaking the normalizer a bit
further, perhaps like so:

    static char *normalize_reflog_message(const char *msg)
    {
            struct strbuf sb = STRBUF_INIT;

            if (msg && *msg)
                    copy_reflog_msg(&sb, msg);
            if (sb.len) {
                    return strbuf_detach(&sb, NULL);
            } else {
                    strbuf_release(&sb);
                    return NULL;
            }
    }

to avoid allocating 1 byte '\0' on the heap by strbuf_detach() when
sb here ends up being truly empty.

But it would be a premature optimization to worry about such a thing
at this point, I think.

Thanks.

  reply	other threads:[~2020-07-10 21:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 12:05 [PATCH 0/4] Preliminary fixes for reftable support Han-Wen Nienhuys via GitGitGadget
2020-06-30 12:05 ` [PATCH 1/4] lib-t6000.sh: write tag using git-update-ref Han-Wen Nienhuys via GitGitGadget
2020-06-30 12:05 ` [PATCH 2/4] t3432: use git-reflog to inspect the reflog for HEAD Han-Wen Nienhuys via GitGitGadget
2020-06-30 12:05 ` [PATCH 3/4] checkout: add '\n' to reflog message Han-Wen Nienhuys via GitGitGadget
2020-06-30 12:05 ` [PATCH 4/4] Treat BISECT_HEAD as a pseudo ref Han-Wen Nienhuys via GitGitGadget
2020-07-07  4:40 ` [PATCH 0/4] Preliminary fixes for reftable support Junio C Hamano
2020-07-10 17:19 ` [PATCH v2 " Han-Wen Nienhuys via GitGitGadget
2020-07-10 17:19   ` [PATCH v2 1/4] lib-t6000.sh: write tag using git-update-ref Han-Wen Nienhuys via GitGitGadget
2020-07-10 17:19   ` [PATCH v2 2/4] t3432: use git-reflog to inspect the reflog for HEAD Han-Wen Nienhuys via GitGitGadget
2020-07-10 17:19   ` [PATCH v2 3/4] Treat BISECT_HEAD as a pseudo ref Han-Wen Nienhuys via GitGitGadget
2020-07-10 17:19   ` [PATCH v2 4/4] Cleanse reflog messages in the refs.c layer Junio C Hamano via GitGitGadget
2020-07-10 21:06     ` Junio C Hamano [this message]
2020-07-10 20:57   ` [PATCH v2 0/4] Preliminary fixes for reftable support Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqtuyfrsg0.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hanwenn@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).