line-log: be more careful when adjusting multiple line ranges

I am a heavy user of git log -L .... In fact, I use the feature where multiple ranges can be specified extensively, via a not-exactly-trivial shell script function that takes the currently staged changes (or if none are staged, the current unstanged changes) and turns them into the corresponding commit history:

staged_log () { #

        diff="$(git diff --cached -U1)"
        test -n "$diff" ||
        diff="$(git diff -U1)"
        test -n "$diff" ||
        die "No changes"
        eval "git log $(echo "$diff" |
                sed -ne '/^--- a\//{s/^-* a\/\(.*\)/'\''\1'\''/;x}' -e \
                        '/^@@ -/{s/^@@ -\([^, ]*\),\([^ ]*\).*/-L \1,+\2/;G;s/\n/:/g;p}' |
                        tr '\n' ' ')"
}

This is an extremely useful way to look at the history, especially when trying to fix up a commit deep in a long branch (or a thicket of branches).

Today, however, this method failed me, by greeting me with an assertion. When I tried to paper over that assertion by joining line ranges that became adjacent (or overlapping), it still produced a segmentation fault when the line-log tried to print lines past the file contents.

So I had no choice but to fix this properly.

I still wanted to keep the optimization where multiple line ranges are joined into a single one (I am convinced that this also affects the output, where previously multiple hunks would have been displayed, but I ran out of time to investigate this). This is the 3rd patch. It is not purely an optimization, as the assertion would still trigger when line ranges could be joined.

Now, I am fairly certain that the changes are correct, but given my track record with off-by-one bugs (and once even an off-by-two bug), I would really appreciate some thorough review of this code, in particular the second one that is the actual bug fix. I am specifically interested in reviews from people who know line-log.c pretty well and can tell me whether the src[i].end > target[j].end is correct, or whether it should actually have been a >= (I tried to wrap my head around this, but I would feel more comfortable if a domain expert would analyze this, whistling, and looking Eric's way).

Johannes Schindelin (4):
line-log: demonstrate a bug with nearly-overlapping ranges
line-log: adjust start/end of ranges individually
line-log: optimize ranges by joining them when possible
line-log: convert an assertion to a full BUG() call

 line-log.c          | 18 +++++++++++++++---
 t/t4211-line-log.sh | 17 +++++++++++++++++
 2 files changed, 32 insertions(+), 3 deletions(-)

base-commit: 1d89318c48d233d52f1db230cf622935ac3c69fa
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-15%2Fdscho%2Fline-log-fix-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-15/dscho/line-log-fix-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/15

gitgitgadget