All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Stefan Tauner <stefan.tauner@gmx.at>
Cc: git@vger.kernel.org
Subject: Re: Un-paged commit messages in git filter-branch's commit-filter?
Date: Mon, 1 Aug 2016 17:36:31 -0400	[thread overview]
Message-ID: <20160801213631.2ttdlermxw2wbnbi@sigill.intra.peff.net> (raw)
In-Reply-To: <0MTjMy-1buKad2Fg8-00QUQV@mail.gmx.com>

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

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

> 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

  reply	other threads:[~2016-08-01 21:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13  6:28 Un-paged commit messages in git filter-branch's commit-filter? Stefan Tauner
2016-06-16  9:59 ` Jeff King
2016-07-31 16:39   ` Stefan Tauner
2016-08-01 21:36     ` Jeff King [this message]
2016-08-01 21:49       ` Stefan Tauner
2016-08-01 23:24         ` Jeff King
2016-08-02  0:07           ` Eric Wong
2016-08-06  9:40           ` Stefan Tauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160801213631.2ttdlermxw2wbnbi@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=stefan.tauner@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.