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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 01, 2016 at 11:49:09PM +0200, Stefan Tauner wrote:

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

One thing to look at, I guess, is whether they are corrupted coming in
to the repository, or when they are being formatted.

If you do:

  git cat-file commit HEAD

you will get the raw bytes of the commit object stored by git. In the
example above, it obviously shows one long line. Have you checked that
it does so in your cases that misbehave?

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

Hmm. The usual problem with svn-imported commits is not long lines,
exactly, but rather that the commit message has one big paragraph at the
top, rather than a subject/body split.

So when you ask git for the "subject" in such a case, it may paste many
lines together as a single one. For example:

  $ commit=$(seq 1 5 | git commit-tree HEAD^{tree})
  $ git cat-file commit $commit
  tree 07753f428765ac1afe2020b24e40785869bd4a85
  author Jeff King <peff@xxxxxxxx> 1470093739 -0400
  committer Jeff King <peff@xxxxxxxx> 1470093739 -0400

  1
  2
  3
  4
  5

  $ git log --format=%s $commit
  1 2 3 4 5

So could it be that your lines actually _are_ broken in the git objects,
but "%s" and other tools try to salvage them as a single subject?

I don't recall offhand whether git-svn does line-wrapping or any other
commit-message munging.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]