summaryrefslogtreecommitdiff
path: root/t/t6011-rev-list-with-bad-commit.sh
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <Johannes.Schindelin@gmx.de>2013-12-27 21:49:57 +0100
committerLibravatar Junio C Hamano <gitster@pobox.com>2013-12-27 16:46:25 -0800
commite228c1736f25c59cd6da51ed97e03ecd80a935e6 (patch)
tree3b9219df5f3a7a34b8e3665fe54a76d78e87608a /t/t6011-rev-list-with-bad-commit.sh
parentGit 1.8.5.2 (diff)
downloadtgif-e228c1736f25c59cd6da51ed97e03ecd80a935e6.tar.xz
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>
Diffstat (limited to 't/t6011-rev-list-with-bad-commit.sh')
0 files changed, 0 insertions, 0 deletions