1GIT-BLAME(1)                      Git Manual                      GIT-BLAME(1)
2
3
4

NAME

6       git-blame - Show what revision and author last modified each line of a
7       file
8

SYNOPSIS

10       git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
11                   [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
12                   [--ignore-rev <rev>] [--ignore-revs-file <file>]
13                   [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>]
14                   [<rev> | --contents <file> | --reverse <rev>..<rev>] [--] <file>
15

DESCRIPTION

17       Annotates each line in the given file with information from the
18       revision which last modified the line. Optionally, start annotating
19       from the given revision.
20
21       When specified one or more times, -L restricts annotation to the
22       requested lines.
23
24       The origin of lines is automatically followed across whole-file renames
25       (currently there is no option to turn the rename-following off). To
26       follow lines moved from one file to another, or to follow lines that
27       were copied and pasted from another file, etc., see the -C and -M
28       options.
29
30       The report does not tell you anything about lines which have been
31       deleted or replaced; you need to use a tool such as git diff or the
32       "pickaxe" interface briefly mentioned in the following paragraph.
33
34       Apart from supporting file annotation, Git also supports searching the
35       development history for when a code snippet occurred in a change. This
36       makes it possible to track when a code snippet was added to a file,
37       moved or copied between files, and eventually deleted or replaced. It
38       works by searching for a text string in the diff. A small example of
39       the pickaxe interface that searches for blame_usage:
40
41           $ git log --pretty=oneline -S'blame_usage'
42           5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
43           ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
44

OPTIONS

46       -b
47           Show blank SHA-1 for boundary commits. This can also be controlled
48           via the blame.blankBoundary config option.
49
50       --root
51           Do not treat root commits as boundaries. This can also be
52           controlled via the blame.showRoot config option.
53
54       --show-stats
55           Include additional statistics at the end of blame output.
56
57       -L <start>,<end>, -L :<funcname>
58           Annotate only the line range given by <start>,<end>, or by the
59           function name regex <funcname>. May be specified multiple times.
60           Overlapping ranges are allowed.
61
62           <start> and <end> are optional.  -L <start> or -L <start>, spans
63           from <start> to end of file.  -L ,<end> spans from start of file to
64           <end>.
65
66           <start> and <end> can take one of these forms:
67
68           •   number
69
70               If <start> or <end> is a number, it specifies an absolute line
71               number (lines count from 1).
72
73/regex/
74
75               This form will use the first line matching the given POSIX
76               regex. If <start> is a regex, it will search from the end of
77               the previous -L range, if any, otherwise from the start of
78               file. If <start> is ^/regex/, it will search from the start of
79               file. If <end> is a regex, it will search starting at the line
80               given by <start>.
81
82           •   +offset or -offset
83
84               This is only valid for <end> and will specify a number of lines
85               before or after the line given by <start>.
86
87           If :<funcname> is given in place of <start> and <end>, it is a
88           regular expression that denotes the range from the first funcname
89           line that matches <funcname>, up to the next funcname line.
90           :<funcname> searches from the end of the previous -L range, if any,
91           otherwise from the start of file.  ^:<funcname> searches from the
92           start of file. The function names are determined in the same way as
93           git diff works out patch hunk headers (see Defining a custom
94           hunk-header in gitattributes(5)).
95
96       -l
97           Show long rev (Default: off).
98
99       -t
100           Show raw timestamp (Default: off).
101
102       -S <revs-file>
103           Use revisions from revs-file instead of calling git-rev-list(1).
104
105       --reverse <rev>..<rev>
106           Walk history forward instead of backward. Instead of showing the
107           revision in which a line appeared, this shows the last revision in
108           which a line has existed. This requires a range of revision like
109           START..END where the path to blame exists in START.  git blame
110           --reverse START is taken as git blame --reverse START..HEAD for
111           convenience.
112
113       --first-parent
114           Follow only the first parent commit upon seeing a merge commit.
115           This option can be used to determine when a line was introduced to
116           a particular integration branch, rather than when it was introduced
117           to the history overall.
118
119       -p, --porcelain
120           Show in a format designed for machine consumption.
121
122       --line-porcelain
123           Show the porcelain format, but output commit information for each
124           line, not just the first time a commit is referenced. Implies
125           --porcelain.
126
127       --incremental
128           Show the result incrementally in a format designed for machine
129           consumption.
130
131       --encoding=<encoding>
132           Specifies the encoding used to output author names and commit
133           summaries. Setting it to none makes blame output unconverted data.
134           For more information see the discussion about encoding in the git-
135           log(1) manual page.
136
137       --contents <file>
138           When <rev> is not specified, the command annotates the changes
139           starting backwards from the working tree copy. This flag makes the
140           command pretend as if the working tree copy has the contents of the
141           named file (specify - to make the command read from the standard
142           input).
143
144       --date <format>
145           Specifies the format used to output dates. If --date is not
146           provided, the value of the blame.date config variable is used. If
147           the blame.date config variable is also not set, the iso format is
148           used. For supported values, see the discussion of the --date option
149           at git-log(1).
150
151       --[no-]progress
152           Progress status is reported on the standard error stream by default
153           when it is attached to a terminal. This flag enables progress
154           reporting even if not attached to a terminal. Can’t use --progress
155           together with --porcelain or --incremental.
156
157       -M[<num>]
158           Detect moved or copied lines within a file. When a commit moves or
159           copies a block of lines (e.g. the original file has A and then B,
160           and the commit changes it to B and then A), the traditional blame
161           algorithm notices only half of the movement and typically blames
162           the lines that were moved up (i.e. B) to the parent and assigns
163           blame to the lines that were moved down (i.e. A) to the child
164           commit. With this option, both groups of lines are blamed on the
165           parent by running extra passes of inspection.
166
167           <num> is optional but it is the lower bound on the number of
168           alphanumeric characters that Git must detect as moving/copying
169           within a file for it to associate those lines with the parent
170           commit. The default value is 20.
171
172       -C[<num>]
173           In addition to -M, detect lines moved or copied from other files
174           that were modified in the same commit. This is useful when you
175           reorganize your program and move code around across files. When
176           this option is given twice, the command additionally looks for
177           copies from other files in the commit that creates the file. When
178           this option is given three times, the command additionally looks
179           for copies from other files in any commit.
180
181           <num> is optional but it is the lower bound on the number of
182           alphanumeric characters that Git must detect as moving/copying
183           between files for it to associate those lines with the parent
184           commit. And the default value is 40. If there are more than one -C
185           options given, the <num> argument of the last -C will take effect.
186
187       --ignore-rev <rev>
188           Ignore changes made by the revision when assigning blame, as if the
189           change never happened. Lines that were changed or added by an
190           ignored commit will be blamed on the previous commit that changed
191           that line or nearby lines. This option may be specified multiple
192           times to ignore more than one revision. If the
193           blame.markIgnoredLines config option is set, then lines that were
194           changed by an ignored commit and attributed to another commit will
195           be marked with a ?  in the blame output. If the
196           blame.markUnblamableLines config option is set, then those lines
197           touched by an ignored commit that we could not attribute to another
198           revision are marked with a *.
199
200       --ignore-revs-file <file>
201           Ignore revisions listed in file, which must be in the same format
202           as an fsck.skipList. This option may be repeated, and these files
203           will be processed after any files specified with the
204           blame.ignoreRevsFile config option. An empty file name, "", will
205           clear the list of revs from previously processed files.
206
207       --color-lines
208           Color line annotations in the default format differently if they
209           come from the same commit as the preceding line. This makes it
210           easier to distinguish code blocks introduced by different commits.
211           The color defaults to cyan and can be adjusted using the
212           color.blame.repeatedLines config option.
213
214       --color-by-age
215           Color line annotations depending on the age of the line in the
216           default format. The color.blame.highlightRecent config option
217           controls what color is used for each range of age.
218
219       -h
220           Show help message.
221
222       -c
223           Use the same output mode as git-annotate(1) (Default: off).
224
225       --score-debug
226           Include debugging information related to the movement of lines
227           between files (see -C) and lines moved within a file (see -M). The
228           first number listed is the score. This is the number of
229           alphanumeric characters detected as having been moved between or
230           within files. This must be above a certain threshold for git blame
231           to consider those lines of code to have been moved.
232
233       -f, --show-name
234           Show the filename in the original commit. By default the filename
235           is shown if there is any line that came from a file with a
236           different name, due to rename detection.
237
238       -n, --show-number
239           Show the line number in the original commit (Default: off).
240
241       -s
242           Suppress the author name and timestamp from the output.
243
244       -e, --show-email
245           Show the author email instead of author name (Default: off). This
246           can also be controlled via the blame.showEmail config option.
247
248       -w
249           Ignore whitespace when comparing the parent’s version and the
250           child’s to find where the lines came from.
251
252       --abbrev=<n>
253           Instead of using the default 7+1 hexadecimal digits as the
254           abbreviated object name, use <m>+1 digits, where <m> is at least
255           <n> but ensures the commit object names are unique. Note that 1
256           column is used for a caret to mark the boundary commit.
257

THE DEFAULT FORMAT

259       When neither --porcelain nor --incremental option is specified, git
260       blame will output annotation for each line with:
261
262       •   abbreviated object name for the commit the line came from;
263
264       •   author ident (by default author name and date, unless -s or -e is
265           specified); and
266
267       •   line number
268
269       before the line contents.
270

THE PORCELAIN FORMAT

272       In this format, each line is output after a header; the header at the
273       minimum has the first line which has:
274
275       •   40-byte SHA-1 of the commit the line is attributed to;
276
277       •   the line number of the line in the original file;
278
279       •   the line number of the line in the final file;
280
281       •   on a line that starts a group of lines from a different commit than
282           the previous one, the number of lines in this group. On subsequent
283           lines this field is absent.
284
285       This header line is followed by the following information at least once
286       for each commit:
287
288       •   the author name ("author"), email ("author-mail"), time
289           ("author-time"), and time zone ("author-tz"); similarly for
290           committer.
291
292       •   the filename in the commit that the line is attributed to.
293
294       •   the first line of the commit log message ("summary").
295
296       The contents of the actual line is output after the above header,
297       prefixed by a TAB. This is to allow adding more header elements later.
298
299       The porcelain format generally suppresses commit information that has
300       already been seen. For example, two lines that are blamed to the same
301       commit will both be shown, but the details for that commit will be
302       shown only once. This is more efficient, but may require more state be
303       kept by the reader. The --line-porcelain option can be used to output
304       full commit information for each line, allowing simpler (but less
305       efficient) usage like:
306
307           # count the number of lines attributed to each author
308           git blame --line-porcelain file |
309           sed -n 's/^author //p' |
310           sort | uniq -c | sort -rn
311

SPECIFYING RANGES

313       Unlike git blame and git annotate in older versions of git, the extent
314       of the annotation can be limited to both line ranges and revision
315       ranges. The -L option, which limits annotation to a range of lines, may
316       be specified multiple times.
317
318       When you are interested in finding the origin for lines 40-60 for file
319       foo, you can use the -L option like so (they mean the same thing — both
320       ask for 21 lines starting at line 40):
321
322           git blame -L 40,60 foo
323           git blame -L 40,+21 foo
324
325       Also you can use a regular expression to specify the line range:
326
327           git blame -L '/^sub hello {/,/^}$/' foo
328
329       which limits the annotation to the body of the hello subroutine.
330
331       When you are not interested in changes older than version v2.6.18, or
332       changes older than 3 weeks, you can use revision range specifiers
333       similar to git rev-list:
334
335           git blame v2.6.18.. -- foo
336           git blame --since=3.weeks -- foo
337
338       When revision range specifiers are used to limit the annotation, lines
339       that have not changed since the range boundary (either the commit
340       v2.6.18 or the most recent commit that is more than 3 weeks old in the
341       above example) are blamed for that range boundary commit.
342
343       A particularly useful way is to see if an added file has lines created
344       by copy-and-paste from existing files. Sometimes this indicates that
345       the developer was being sloppy and did not refactor the code properly.
346       You can first find the commit that introduced the file with:
347
348           git log --diff-filter=A --pretty=short -- foo
349
350       and then annotate the change between the commit and its parents, using
351       commit^! notation:
352
353           git blame -C -C -f $commit^! -- foo
354

INCREMENTAL OUTPUT

356       When called with --incremental option, the command outputs the result
357       as it is built. The output generally will talk about lines touched by
358       more recent commits first (i.e. the lines will be annotated out of
359       order) and is meant to be used by interactive viewers.
360
361       The output format is similar to the Porcelain format, but it does not
362       contain the actual lines from the file that is being annotated.
363
364        1. Each blame entry always starts with a line of:
365
366               <40-byte hex sha1> <sourceline> <resultline> <num_lines>
367
368           Line numbers count from 1.
369
370        2. The first time that a commit shows up in the stream, it has various
371           other information about it printed out with a one-word tag at the
372           beginning of each line describing the extra commit information
373           (author, email, committer, dates, summary, etc.).
374
375        3. Unlike the Porcelain format, the filename information is always
376           given and terminates the entry:
377
378               "filename" <whitespace-quoted-filename-goes-here>
379
380           and thus it is really quite easy to parse for some line- and
381           word-oriented parser (which should be quite natural for most
382           scripting languages).
383
384               Note
385               For people who do parsing: to make it more robust, just ignore
386               any lines between the first and last one ("<sha1>" and
387               "filename" lines) where you do not recognize the tag words (or
388               care about that particular one) at the beginning of the
389               "extended information" lines. That way, if there is ever added
390               information (like the commit encoding or extended commit
391               commentary), a blame viewer will not care.
392

MAPPING AUTHORS

394       See gitmailmap(5).
395

CONFIGURATION

397       Everything below this line in this section is selectively included from
398       the git-config(1) documentation. The content is the same as what’s
399       found there:
400
401       blame.blankBoundary
402           Show blank commit object name for boundary commits in git-blame(1).
403           This option defaults to false.
404
405       blame.coloring
406           This determines the coloring scheme to be applied to blame output.
407           It can be repeatedLines, highlightRecent, or none which is the
408           default.
409
410       blame.date
411           Specifies the format used to output dates in git-blame(1). If unset
412           the iso format is used. For supported values, see the discussion of
413           the --date option at git-log(1).
414
415       blame.showEmail
416           Show the author email instead of author name in git-blame(1). This
417           option defaults to false.
418
419       blame.showRoot
420           Do not treat root commits as boundaries in git-blame(1). This
421           option defaults to false.
422
423       blame.ignoreRevsFile
424           Ignore revisions listed in the file, one unabbreviated object name
425           per line, in git-blame(1). Whitespace and comments beginning with #
426           are ignored. This option may be repeated multiple times. Empty file
427           names will reset the list of ignored revisions. This option will be
428           handled before the command line option --ignore-revs-file.
429
430       blame.markUnblamableLines
431           Mark lines that were changed by an ignored revision that we could
432           not attribute to another commit with a * in the output of git-
433           blame(1).
434
435       blame.markIgnoredLines
436           Mark lines that were changed by an ignored revision that we
437           attributed to another commit with a ?  in the output of git-
438           blame(1).
439

SEE ALSO

441       git-annotate(1)
442

GIT

444       Part of the git(1) suite
445
446
447
448Git 2.39.1                        2023-01-13                      GIT-BLAME(1)
Impressum