2012/2/10 Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>: >> I tried this in the past and "git log -p" looked ugly on git.git >> mainly because commit messages are still ~70 char long lines on my 279 >> char wide terminal. If this is project dependent, perhaps a config >> key? Also the "50" below the changed line, maybe you want to change it >> to 0.6 * width. > > > Thanks for all the comments. I'll post a newer version, but I have two > questions: > > I agree that making the output very wide with lots of +- is not very > elegant. (E.g. 8f24a6323ece9be1bf1a04b4b5856112438337f2 has > builtin/grep.c | 142 +++--------------------------------....-- > which doesn't look right.). So I think it would make sense to limit > the graph part to something like 50 columns, even if there's more space. > I believe that git.git would look fine with this change. There are some > fairly long lines > (t/t4013/diff.format-patch_--inline_--stdout_--subject-prefix=TESTCASE_initial..master > is 86 chars) but with 50 columns of graph the output would take 140 columns > -- with the graph part slightly sticking out from the 80 column > descriptions, but still not too ugly. You also need to pay attention, not to exceed term_columns() because of this dynamic name part. But the idea sounds good to me. It would be even better if we had some heuristics to shorten exceptionally long names with ellipsis, to keep the name part from being overly stretched. > Should I add a new option --stat-graph-width in analogy to > --stat-name-width, or should this be hard-coded? I don't know about other people, but I have no urge to change graph width. -- Duy -- 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