On Wed, Apr 29, 2015 at 12:39:47AM -0400, Jeff King wrote:
> So I can't figure out how to replicate the problem here.
Actually, that's not quite true. I could get hold of an OS X system to
replicate, which I just did.
The problem is that commit 3b754f212 does not have a newline at the end
of its commit message, and the OS X version of sed doesn't preserve
that.
Here's a much smaller reproduction recipe:
git init
echo content >file
git add file
tree=$(git write-tree)
commit=$(printf 'no newline' | git commit-tree $tree)
git update-ref HEAD $commit
git filter-branch
On my Linux system, this results in an unchanged history, but on OS X,
the commit is rewritten to have a newline at the end of the commit
message.
The culprit is this line from git-filter-branch:
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" > ../message ||
die "msg filter failed: $filter_msg"
The "sed" command silently appends an extra newline to the final line of
the message. You can see the sed behavior more directly with:
printf foo | sed -ne 1p
which adds a newline on OS X, but not when using GNU sed on Linux. It
looks like OS X has just BSD sed, so the same behavior probably happens
on FreeBSD and elsewhere.
I'm not sure of a solution short of replacing the use of sed here with
something else. perl would be a simple choice, but filter-branch does
not otherwise depend on it. We could use a shell "read" loop, but those
are quite slow (and filter-branch is slow enough as it is!).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
