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: Mark Ruvald Pedersen via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Mark Ruvald Pedersen <mped@oticon.com>,
	Mark Ruvald Pedersen <mped@demant.com>
Subject: Re: [PATCH 1/2] sequencer: truncate labels to accommodate loose refs
Date: Wed, 16 Aug 2023 09:28:57 -0700	[thread overview]
Message-ID: <xmqqcyzneyt2.fsf@gitster.g> (raw)
In-Reply-To: <42dd6b6f-4d33-724c-ab15-ba7bb5ead733@gmx.de> (Johannes Schindelin's message of "Wed, 16 Aug 2023 10:36:33 +0200 (CEST)")

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

> It is not a performance-critical code path, so I erred on the side of
> simplicity (although I have to admit that the post image of the diff is
> not exactly for the faint of heart).
>
> Could we maybe form the plan to keep in the back of our heads that we
> already have a UTF-8-truncating functionality in sequencer, and in case
> another user should turn up, implemnt that optimized function in
> `utf8.[ch]`?

Yup, that is a good idea.  Even though this one only cares about the
bytecount, we'd eventually benefit from two variants, truncate by
bytecount and truncate by display width.  Both variants should
return an error when given a bytestring that does not make a valid
UTF-8 sequence, and leave it to the caller to truncate at byte
boundary as a fallback, which is trivial (the alternative would be
to do the truncation by the callee, but then caller cannot tell if
the returned result is a fallback result that the end user may need
to be warned about or a known-valid UTF-8 substring if we go that
route, so it would be suboptimal).

Thanks.



  reply	other threads:[~2023-08-16 16:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 16:34 [PATCH 0/2] sequencer: truncate lockfile and ref to NAME_MAX Mark Ruvald Pedersen via GitGitGadget
2023-08-10 16:34 ` [PATCH 1/2] sequencer: truncate labels to accommodate loose refs Mark Ruvald Pedersen via GitGitGadget
2023-08-10 17:12   ` Junio C Hamano
2023-08-16  8:36     ` Johannes Schindelin
2023-08-16 16:28       ` Junio C Hamano [this message]
2023-08-10 16:35 ` [PATCH 2/2] rebase: allow overriding the maximal length of the generated labels Johannes Schindelin via GitGitGadget
2023-08-10 17:15   ` 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

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

  git send-email \
    --in-reply-to=xmqqcyzneyt2.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=mped@demant.com \
    --cc=mped@oticon.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.
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).