[PATCH] blame: document actual range specifier behavior

[Daniel Koning <dk@danielkoning.com>]

The git-blame(1) man page says that the .. range specifier can be used
to exclude changes "older than" a certain revision. It goes on to say
that it collapses all lines "not changed since the range boundary" into
the boundary revision. This is the same thing --since=<rev-date> would
do, and the man page even uses .. and --since in parallel as if to imply
that they're alternative means of achieving the same output.

In fact, this isn't true! On the git-rev-list(1) and gitrevisions(7) man
pages, it's explained that the .. specifier excludes all ancestors of
the commit, not all commits on an earlier date. 'blame' is not an
exception to this behavior; it uses the same functions as other commands
to parse a specifier and build a revision set.

If you execute:

----
#!/bin/sh

mkdir blame-test
pushd blame-test

git init
echo "line added at root" > foo
echo "another line added at root" >> foo
git add foo
git commit -am "#1 chronologically"

git checkout -b side
sed '2i\
    line added only on side branch
    ' foo > bar
mv bar foo
git commit -am "#2 chronologically"

git checkout master
echo "line added only on master branch" >> foo
git commit -am "#3 chronologically"
git tag boundary

git merge side -m "#4 chronologically"

git blame boundary.. foo

popd blame-test
----

then you'll see that 'blame' treats the range specifier as 'rev-list'
would: the second line is attributed to a commit which occured
chronologically before `boundary`.

(I guess a case could be made for an off-kilter interpretation of the
phrasing, under which "since the range boundary" includes any commits
not yet known to that boundary. But that would contradict the use of
"since" as the name of the other limiting option, which *does* perform
an absolute time cutoff.)

There is at least one porcelain in fairly wide use which takes this
passage of the manual at its word, so I'm not the only one who finds it
confusing. I think the phrasing in the following patch is both clearer
and more accurate.

Signed-off-by: Daniel Koning <dk@danielkoning.com>
---
 Documentation/git-blame.txt | 32 ++++++++++++++++++++------------
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 16323eb80e..91f3184e56 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -152,18 +152,26 @@ Also you can use a regular expression to specify the line range:

 which limits the annotation to the body of the `hello` subroutine.

-When you are not interested in changes older than version
-v2.6.18, or changes older than 3 weeks, you can use revision
-range specifiers  similar to 'git rev-list':
-
-	git blame v2.6.18.. -- foo
-	git blame --since=3.weeks -- foo
-
-When revision range specifiers are used to limit the annotation,
-lines that have not changed since the range boundary (either the
-commit v2.6.18 or the most recent commit that is more than 3
-weeks old in the above example) are blamed for that range
-boundary commit.
+When you are only interested in recent changes, you can use revision
+range specifiers and limiting options, just as with 'git rev-list'.
+
+You can limit the annotation to commits from the past 3 weeks:
+
+  git blame --since=3.weeks -- foo
+
+The oldest commit in that span of time will be given the blame for any
+lines that have not changed since.
+
+Or you can limit the annotation to commits that are not ancestors of
+v2.6.18:
+
+  git blame v2.6.18.. -- foo
+
+Unlike the --since option, the two-dot range specifier does not perform
+a date-based cutoff. If changes from branch `fix` were merged in after
+v2.6.18, the commits on `fix` which introduced those changes will appear
+in the output of 'git blame', even if those commits took place at an
+earlier time than v2.6.18.

 A particularly useful way is to see if an added file has lines
 created by copy-and-paste from existing files.  Sometimes this
--
2.20.1