Re: Bug report : bad filter-branch (OSX only)

[Jeff King <peff@peff.net>]

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