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
next prev parent 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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).