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

On Mon, 1 Aug 2016 17:36:31 -0400
Jeff King [off-list ref] wrote:

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

quoted

quoted

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?".

Yes, sorry.
And this is the most amazing thing about this behavior... what's so
different between format-patch and log or show --pretty=%B. Shouldn't
these match 100%?

quoted

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.

That's approximately what I did in my tests as well. And like you, when
I do this in a fresh repository, it works like that..

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.

as well as filter-branch. That's what I meant when I wrote I cannot
reproduce it with a new repository (to create a MWE). I wrote the first
mail under the presumption that filter-branch is somehow involved but
apparently it is not the only git command and receives the mangled
input already as the commands stated in the last email show.

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).

The commit messages I try to process are nothing special really... just
very long and not subject-like (because SVN and not giving too much
thought to them sometimes). The only special thing I can think of is
that they have been processed by git-svn earlier.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner