interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
-development history for when a code snippet occured in a change. This makes it
+development history for when a code snippet occurred in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. It works by searching for
a text string in the diff. A small example:
Use the same output mode as gitlink:git-annotate[1] (Default: off).
-L n,m::
- Annotate only the specified line range (lines count from
- 1). The range can be specified with a regexp. For
- example, `-L '/^sub esc_html /,/^}$/'` limits the
- annotation only to the body of `esc_html` subroutine.
+ Annotate only the specified line range (lines count from 1).
-l, --long::
Show long rev (Default: off).
--------------------
In this format, each line is output after a header; the
-header at the minumum has the first line which has:
+header at the minimum has the first line which has:
- 40-byte SHA-1 of the commit the line is attributed to;
- the line number of the line in the original file;
header elements later.
-SPECIFIYING RANGES
-------------------
+SPECIFYING RANGES
+-----------------
Unlike `git-blame` and `git-annotate` in older git, the extent
of annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
-ll. 40-60 for file `foo`, you can use `-L` option like this:
+ll. 40-60 for file `foo`, you can use `-L` option like these
+(they mean the same thing -- both ask for 21 lines starting at
+line 40):
git blame -L 40,60 foo
+ git blame -L 40,+21 foo
+
+Also you can use regular expression to specify the line range.
+
+ git blame -L '/^sub hello {/,/^}$/' foo
+
+would limit the annotation to the body of `hello` subroutine.
When you are not interested in changes older than the version
v2.6.18, or changes older than 3 weeks, you can use revision