Re: Un-paged commit messages in git filter-branch's commit-filter?

From: Jeff King <peff@peff.net>
Date: Aug 1, 2016, 21:36 UTC
Message-ID: <20160801213631.2ttdlermxw2wbnbi@sigill.intra.peff.net>
In-Reply-To: <0MTjMy-1buKad2Fg8-00QUQV@mail.gmx.com>

On Sun, Jul 31, 2016 at 06:39:35PM +0200, Stefan Tauner wrote:

Show 20 quoted lines

> > There are some output formats that will wrap lines, but by default,
> > filter-branch should not be using them (and I could not reproduce the
> > issue in a simple test). Can you show us what your commit-filter looks
> > like?
> 
> Thanks for your answer. I have tried to reproduce it in other (newly
> created) repositories but failed. However, it seems to relate to some
> kind of persistent paging setting, is that possible?
> git config -l does not show anything suspicious.
> 
> The following commands produce paged output:
> git show hash
> git show --pretty=%B
> git log hash^..hash
> Commit message in gitk
> 
> 
> These do NOT produce paged output:
> git patch hash^..hash
> Commit message in gitg 0.2.7

What is "git patch"? An alias for "format-patch?".

Show 9 quoted lines

> This is the script I tried to use to reproduce the problem:
> 
> #!/bin/bash
> export LC_ALL=C
> input=$(cat)
> echo "===========================
> $input
> ===========================" >> /tmp/paging_bug.txt
> git commit-tree "$@" -m "$input"

Can you be more specific about the input you're feeding to git and the output you're seeing?

For instance, if I do:

  git init
  echo content >file
  git add file
  git commit -m "$(perl -e 'print join(" ", 1..100)')"

I get a commit message with one long unwrapped line, which I can view via git-log, etc. Now if I try to run filter-branch on that:

  git filter-branch --commit-filter '
	input=$(cat)
	{
		echo "===================="
		echo $input
		echo "===================="
	} >>/tmp/paging_bug.txt
	git commit-tree "$@" -m "$input"
  '

then the commit remains unchanged, and paging_bug shows one long line. What am I missing?

(I wondered at first if the extra "cat" and "-m" could be messing up whitespace for you, but it should not, as the quoting around "$input" should preserve things like newlines. And anyway, the bug in that case would be the _opposite_; I'd expect it to stuff everything onto a single line rather than breaking lines).

-Peff