Subject: Re: What's cooking in git.git (Sep 2018, #01; Tue, 4)

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Wed, 05 Sep 2018 10:29:21 +0200

On Tue, Sep 04 2018, Junio C Hamano wrote:

> Git 2.19-rc2 is out.  Hopefully the tip of 'master' is more or less
> identical to the final one without needing much updates.
>
> You can find the changes described here in the integration branches
> of the repositories listed at
>
>     http://git-blame.blogspot.com/p/git-public-repositories.html
>
> --------------------------------------------------
> [Graduated to "master"]
>
> * ab/portable (2018-08-27) 6 commits
>   (merged to 'next' on 2018-08-27 at 37640e66ef)
>  + tests: fix and add lint for non-portable grep --file
>  + tests: fix version-specific portability issue in Perl JSON
>  + tests: use shorter labels in chainlint.sed for AIX sed
>  + tests: fix comment syntax in chainlint.sed for AIX sed
>  + tests: fix and add lint for non-portable seq
>  + tests: fix and add lint for non-portable head -c N
>  (this branch is used by ab/portable-more.)

I recently gained access to a Solaris 10 SPARC (5.10) box and discovered
that the chainlint.sed implementation in 2.19.0 has more sed portability
issues.

First, whoever implemented the /bin/sed on Solaris apparently read the
POSIX requirements for a max length label of 8 to mean that 8 characters
should include the colon, so a bunch of things fail because of that, but
are fixed with a shorter 7 character label.

Then GIT_TEST_CHAIN_LINT=1 still fails because 878f988350 ("t/test-lib:
teach --chain-lint to detect broken &&-chains in subshells", 2018-07-11)
added a "grep -q" invocation. The /bin/grep on that version of Solaris
doesn't have -q. We fixed a similar issue way back in 80700fde91
("t/t1304: make a second colon optional in the mask ACL check",
2010-03-15) by redirecting to /dev/null instead.

A bunch of other tests in the test suite rely on "grep -q", but nothing
as central as chainlint, so it makes everything break. Do we want to
away with "grep -q" entirely because of old Solaris /bin/grep?

At this point those familiar with Solaris are screaming ("why are you
using anything in /bin!"). Okey fine, but it mostly worked before, so
are we OK with breaking it? "Mostly" here is "test suite would fail
20-30 tests for various reasons, but at least no failures in test-lib.sh
and the like".

However, if as config.mak.uname does we run the tests with
PATH=/usr/xpg6/bin:/usr/xpg4/bin:$PATH, at this point sed is fine with 8
character labels, but starts complaining about this (also in
chainlint.sed):

    sed: Too many commands, last: s/\n//

As with other sed issues I fixed recently in chainlint.sed this one is
just the tip of the iceberg. Once you "fix" one (just remove it, I have
no idea how to rewrite it) others appear.

I was hoping this would just be a Solaris 10 issue, but it's also an
issue in Solaris 11 (5.11 11.3).

So, do we want to chase this down or just do this?:

    diff --git a/Makefile b/Makefile
    index 5a969f5..f125dc5 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -2602,6 +2602,9 @@ endif
     ifdef TEST_GIT_INDEX_VERSION
            @echo TEST_GIT_INDEX_VERSION=\''$(subst ','\'',$(subst ','\'',$(TEST_GIT_INDEX_VERSION)))'\' >>$@+
     endif
    +ifdef GIT_TEST_CHAIN_LINT
    +       @echo GIT_TEST_CHAIN_LINT=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_CHAIN_LINT)))'\' >>$@+
    +endif
            @if cmp $@+ $@ >/dev/null 2>&1; then $(RM) $@+; else mv $@+ $@; fi

     ### Detect Python interpreter path changes
    diff --git a/config.mak.uname b/config.mak.uname
    index e47af72..2b02a2b 100644
    --- a/config.mak.uname
    +++ b/config.mak.uname
    @@ -163,6 +163,10 @@ ifeq ($(uname_S),SunOS)
            INSTALL = /usr/ucb/install
            TAR = gtar
            BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__
    +       # t/chainlint.sed is hopelessly broken all known (tested
    +       # Solaris 10 & 11) versions of Solaris, both /bin/sed and
    +       # /usr/xpg4/bin/sed
    +       GIT_TEST_CHAIN_LINT = 0
     endif
     ifeq ($(uname_O),Cygwin)
            ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)

If I could wave a magic wand I'd say "let's just rewrite chainlint.sed
in perl, at least that's portable", but that's a lot of effort (and I
doubt Eric wants to). It slightly sucks to not have chainlint on
Solaris, but it would also suck to revert chainlint.sed back to 2.18.0
(there were some big improvements). So I think the patch above is the
best way forward, especially since we're on rc2. What do you think?