Re: Un-paged commit messages in git filter-branch's commit-filter?
- From
- Stefan Tauner <stefan.tauner@gmx.at>
- Date
- Aug 1, 2016, 21:49 UTC
- Message-ID
- <0LzskF-1bGAH81g5T-014za7@mail.gmx.com>
- In-Reply-To
- <20160801213631.2ttdlermxw2wbnbi@sigill.intra.peff.net>
On Mon, 1 Aug 2016 17:36:31 -0400 Jeff King <peff@peff.net> wrote:
Show 24 quoted lines
> 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?".
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%?
Show 23 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.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..
Show 13 quoted lines
> 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.
Show 7 quoted lines
> 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