That appeared to work, Dave, thanks!  I've gone ahead and committed that fix to source.squeak.org/ss, and uploaded a patch.st file to the server.

I would say Christoph is now free to take care of his request himself.

Regards,
  Chris

On Sat, Oct 8, 2022 at 4:52 PM David T. Lewis <lewis@mail.msen.com> wrote:
On Sat, Oct 08, 2022 at 03:48:28PM -0500, Chris Muller wrote:
> Hi Christoph,
>
> > unfortunately, I have already uploaded Regex-Core-ct.78 which merges Regex-Core-ct.74,
> > i.e., references it as an ancestor. I only noticed afterward that this
> > version has an incorrect encoding. So we seem to have two options:
> >
> >
> >
> >    1. Move Regex-Core-ct.74 to the Trunk indeed and hope that it won't
> >    make any further problems in the future. (You can still view it from the
> >    image, just not from source.squeak.org.)
> >    2. Remove Regex-Core-ct.78 from the trunk (move it to treated) and
> >    create a new merge commit that excludes Regex-Core-ct.74. But I don't know
> >    how this will influence the update stream and the images of people who have
> >    already installed the latest updates.
> >
> >
> Option 2.  Make a new .74 as .79 with the correct encoding.  Then make a
> .80 that merges it all together.  We will get rid of .74 and .78.  If
> you're worried about development images of an early alpha, then add a
> postScript to the .80 that fixes their MCWorkingCopy's ancestry (by
> removing .74 and .78).
>

This sounds like a lot of work. How about option 3, fix the rendering
on SqueakSource. There is no reason that Unicode wide characters should
be prohibited in commit notices.

The patch is simple, see attached or load SqueakSource-dtl.1145 from the
repository. I installed it already on squeaksource.com, but I'm not sure
if it should be a patch or an image update on source.squeak.org.

Dave