From: Jeff King <hidden> Date: 2016-06-15 22:44:36
I've been setting up auto-builders for a few platforms to try to catch
portability problems early. Unfortunately, it was made harder by the
fact that the _current_ test scripts don't pass on all platforms.
With these patches, I can successfully run all test scripts from the
current 'master' on FreeBSD 6.1 (some of them probably affect OS X, too
-- I recall somebody complaining about the '! foo | bar' construct
recently).
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:44:36
On some shells (notably /bin/sh on FreeBSD 6.1), the
construct
! foo | bar
does not negate the exit value of the pipeline, but rather
of 'foo', producing the opposite of the expected value. We
can work around this by specifying it as
! (foo | bar)
Signed-off-by: Jeff King <redacted>
---
git-rebase.sh | 2 +-
t/t3400-rebase.sh | 4 ++--
t/t3700-add.sh | 6 +++---
t/t7501-commit.sh | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
@@ -353,7 +353,7 @@ orig_head=$branchmb=$(gitmerge-base"$onto""$branch")iftest"$upstream"="$onto"&&test"$mb"="$onto"&&# linear history?-!gitrev-list--parents"$onto".."$branch"|grep" .* ">/dev/null+!(gitrev-list--parents"$onto".."$branch"|grep" .* ")>/dev/nullthen# Lazily switch to the target branch if needed...test-z"$switch_to"||gitcheckout"$switch_to"
@@ -44,13 +44,13 @@ test_expect_success 'rebase against master' ' test_expect_success\'the rebase operation should not have destroyed author information'\-'! git log | grep "Author:" | grep "<>"'+'! (git log | grep "Author:" | grep "<>")' test_expect_success'rebase after merge master''gitreset--hardtopic&&gitmergemaster&&gitrebasemaster&&-!gitshow|grep"^Merge:"+!(gitshow|grep"^Merge:")' test_expect_success'rebase of history with merges is linearized''
@@ -81,17 +81,17 @@ test_expect_success '.gitignore test setup' ' test_expect_success'.gitignore is honored''gitadd.&&-!gitls-files|grep"\\.ig"+!(gitls-files|grep"\\.ig")' test_expect_success'error out when attempting to add ignored ones without -f''!gitadda.??&&-!gitls-files|grep"\\.ig"+!(gitls-files|grep"\\.ig")' test_expect_success'error out when attempting to add ignored ones without -f''!gitaddd.??&&-!gitls-files|grep"\\.ig"+!(gitls-files|grep"\\.ig")' test_expect_success'add ignored ones with -f''
From: Jeff King <hidden> Date: 2016-06-15 22:44:36
The output of 'tar tv' varies from system to system. In
particular, the t5000 was expecting to parse the date from
something like:
-rw-rw-r-- root/root 0 2008-05-13 04:27 file
but FreeBSD's tar produces this:
-rw-rw-r-- 0 root root 0 May 13 04:27 file
Instead of relying on tar's output, let's just extract the
file using tar and stat the result using perl.
Signed-off-by: Jeff King <redacted>
---
t/t5000-tar-tree.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:44:36
When using /bin/sh from FreeBSD 6.1, the value of $? is lost
when calling a function inside the 'trap' action. This
resulted in clone erroneously indicating success when it
should have reported failure.
As a workaround, we save the value of $? before calling any
functions.
Signed-off-by: Jeff King <redacted>
---
git-clone.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:44:36
filter-branch tries to restore "old" copies of some
environment variables by using the construct:
unset var
test -z "$old_var" || var="$old_var" && export var
However, by the short-circuit logic, we will always run
'export var'. On bash and dash, exporting an unset variable
has no effect. However, on some shells (such as FreeBSD's
/bin/sh), the shell exports the empty value.
This manifested itself in this case as git-filter-branch
setting GIT_INDEX_FILE to the empty string, which in turn
caused its call to git-read-tree to fail, leaving the
working tree pointing at the original HEAD instead of the
rewritten one.
To fix this, we change the short-circuit logic to better
match the intent:
test -z "$old_var" || { var="$old_var" && export var; }
Signed-off-by: Jeff King <redacted>
---
git-filter-branch.sh | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
From: Jeff King <hidden> Date: 2016-06-15 22:44:36
On Tue, May 13, 2008 at 04:43:39AM -0400, Jeff King wrote:
With these patches, I can successfully run all test scripts from the
current 'master' on FreeBSD 6.1 (some of them probably affect OS X, too
-- I recall somebody complaining about the '! foo | bar' construct
recently).
Ah, nevermind about OS X. It was 97ad535b from Alex, and he specifically
mentioned FreeBSD 4.
Alex, you might want to try re-running the tests with these patches.
-Peff
From: Alex Riesen <hidden> Date: 2016-06-15 22:44:36
Jeff King, Tue, May 13, 2008 11:04:24 +0200:
On Tue, May 13, 2008 at 04:43:39AM -0400, Jeff King wrote:
quoted
With these patches, I can successfully run all test scripts from the
current 'master' on FreeBSD 6.1 (some of them probably affect OS X, too
-- I recall somebody complaining about the '! foo | bar' construct
recently).
Ah, nevermind about OS X. It was 97ad535b from Alex, and he specifically
mentioned FreeBSD 4.
Alex, you might want to try re-running the tests with these patches.
Very good! GnuPG is missing on the system, so t7004 was skipped,
but everything besides that ran fine. My config.mak:
NO_STRTOUMAX=Yes
NO_C99_FORMAT=Yes
SHELL_PATH=/usr/local/bin/bash
perl 5.8.6
I also have the test-tr patches I sent some time ago in that tree.
From: Alex Riesen <hidden> Date: 2016-06-15 22:44:36
Alex Riesen, Tue, May 13, 2008 22:39:31 +0200:
Jeff King, Tue, May 13, 2008 11:04:24 +0200:
quoted
On Tue, May 13, 2008 at 04:43:39AM -0400, Jeff King wrote:
quoted
With these patches, I can successfully run all test scripts from the
current 'master' on FreeBSD 6.1 (some of them probably affect OS X, too
-- I recall somebody complaining about the '! foo | bar' construct
recently).
Ah, nevermind about OS X. It was 97ad535b from Alex, and he specifically
mentioned FreeBSD 4.
Alex, you might want to try re-running the tests with these patches.
Very good! GnuPG is missing on the system, so t7004 was skipped,
but everything besides that ran fine. My config.mak:
NO_STRTOUMAX=Yes
NO_C99_FORMAT=Yes
SHELL_PATH=/usr/local/bin/bash
perl 5.8.6
I also have the test-tr patches I sent some time ago in that tree.
Which is obviously a hack, but I considered too minor an issue. It
(the missing uintmax_t) is probably something very specific to this
particular system. I am probably wrong about the issue being minor...