Remove the line length limit for graft files
authorJohannes Schindelin <Johannes.Schindelin@gmx.de>
Fri, 27 Dec 2013 20:49:57 +0000 (21:49 +0100)
committerJunio C Hamano <gitster@pobox.com>
Sat, 28 Dec 2013 00:46:25 +0000 (16:46 -0800)
commite228c1736f25c59cd6da51ed97e03ecd80a935e6
tree3b9219df5f3a7a34b8e3665fe54a76d78e87608a
parent5512ac5840c8bcaa487806cf402ff960091ab244
Remove the line length limit for graft files

Support for grafts predates Git's strbuf, and hence it is understandable
that there was a hard-coded line length limit of 1023 characters (which
was chosen a bit awkwardly, given that it is *exactly* one byte short of
aligning with the 41 bytes occupied by a commit name and the following
space or new-line character).

While regular commit histories hardly win comprehensibility in general
if they merge more than twenty-two branches in one go, it is not Git's
business to limit grafts in such a way.

In this particular developer's case, the use case that requires
substantially longer graft lines to be supported is the visualization of
the commits' order implied by their changes: commits are considered to
have an implicit relationship iff exchanging them in an interactive
rebase would result in merge conflicts.

Thusly implied branches tend to be very shallow in general, and the
resulting thicket of implied branches is usually very wide; It is
actually quite common that *most* of the commits in a topic branch have
not even one implied parent, so that a final merge commit has about as
many implied parents as there are commits in said branch.

[jc: squashed in tests by Jonathan]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/blame.c
commit.c
t/annotate-tests.sh
t/t6101-rev-parse-parents.sh