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?
