92cf602e3809 - main - Copy strcasestr.c from libc to libkern.

[Warner Losh]

On Fri, Jan 8, 2021 at 1:58 PM Konstantin Belousov <kostikbel at gmail.com>
wrote:

> On Fri, Jan 08, 2021 at 07:46:31AM -0600, Kyle Evans wrote:
> > On Fri, Jan 8, 2021 at 3:27 AM Baptiste Daroussin <bapt at freebsd.org>
> wrote:
> > >
> > > On Fri, Jan 08, 2021 at 02:49:31AM +0300, Vladimir Kondratyev wrote:
> > > > On 08.01.2021 02:41, Ravi Pokala wrote:
> > > > > -----Original Message-----
> > > > > From: <owner-src-committers at freebsd.org> on behalf of Vladimir
> Kondratyev <vladimir at kondratyev.su>
> > > > > Date: 2021-01-07, Thursday at 15:33
> > > > > To: Jessica Clarke <jrtc27 at freebsd.org>, Vladimir Kondratyev
> <wulf at FreeBSD.org>
> > > > > Cc: "src-committers at freebsd.org" <src-committers at FreeBSD.org>, "
> dev-commits-src-all at freebsd.org" <dev-commits-src-all at FreeBSD.org>, "
> dev-commits-src-main at freebsd.org" <dev-commits-src-main at FreeBSD.org>
> > > > > Subject: Re: git: 92cf602e3809 - main - Copy strcasestr.c from
> libc to libkern.
> > > > >
> > > > >     On 08.01.2021 02:27, Jessica Clarke wrote:
> > > > >     > On 7 Jan 2021, at 23:20, Vladimir Kondratyev
> <wulf at FreeBSD.org> wrote:
> > > > >     >> +#include <ctype.h>
> > > > >     >> +#include <string.h>
> > > > >     >> +#include "xlocale_private.h"
> > > > >     >> +
> > > > >     >> +/*
> > > > >     >> + * Find the first occurrence of find in s, ignore case.
> > > > >     >> + */
> > > > >     >> +char *
> > > > >     >> +strcasestr_l(const char *s, const char *find, locale_t
> locale)
> > > > >     >
> > > > >     > Locales in the kernel? This feels wrong.
> > > > >     >
> > > > >     > Jess
> > > > >     >
> > > > >
> > > > >     strcasestr.c was copied from userland unmodified just to allow
> > > > >     "git log --follow" to work. Next commit removed locale support
> from this
> > > > >     file and connected it to build.
> > > > >
> > > > > Unfortunately, about two-dozen commit messages from you arrived at
> the same time, and some were out of order; without incrementing change
> numbers in the subject line, figuring out the actual ordering is
> non-trivial. :-p
> > > > >
> > > > > -Ravi (rpokala@)
> > > > >
> > > >
> > > > I hope, commit hook will be improved some day. Pushing of two-dozen
> > > > commits one by one is too boring.
> > >
> > > The history is in the right order and gitlog/cgit/anything that reads
> the log
> > > show everything in the right order.
> > >
> > > mails are asynchronuous, expecting the mail to always arrive in a
> given order is
> > > wrong ;)
> > >
> > > pushing all those commits at once was imho the right thing to do.
> > >
> >
> > I've pointed this out a couple of times (with seemingly nothing coming
> > from it), but the mails are being sent in reverse order. Fixing that
> > would at least increase chances for some to receive them in order (and
> > the archives show them perfectly in reverse order most of the time).
> >
> > Picking out the message-ids from the last series I sent, this is the
> > correct order:
> >
> > 202101072237.107MbYaX002789 at gitrepo.freebsd.org ("4832d2e8ae1d - main
> > - du: tests: fix the H_flag test (primarily grep usage)")
> > 202101072237.107MbYsM002771 at gitrepo.freebsd.org ("3c5c39c7ad8f - main
> > - du: tests: make H_flag tests more strict about output requirements")
> >
> > 202101072237.107MbYaX002789 -> 2789 was the last pid that assigned a
> message-id
> > 202101072237.107MbYsM002771 -> 2771 was the last pid that assigned a
> message-id
> >
> > Given that this is clearly with kern.randompid=0 on the server, one
> > can conclude that these were sent in the reverse order based on the
> > pid sequence. If you pick a couple other series out, this holds true
> > (at least for all the series I've looked at)
>
> Might be instead of trying to establish ordering by date, sending machinery
> could set followup/in-reply-to headers to thread the whole batch.
> Basically
> emulate the 'git send-email' behavior.
>
> Then we can argue that only related patches should be committed in one
> push, but practically that matches common workflow of developing on
> topic branches and pushing them in one go.
> it is guaranteed
>

I believe that https://github.com/git-multimail/git-multimail is being
considered. It does what you suggest (or something similar).

I'm not sure how well supported it is (it was written years ago, but has
had some recent commits), or how  well it meets our needs, but in the long
run we'll need to do something like this.

Warner