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                   [--progress] [--abbrev=<n>] [<rev> | --contents <file> | --reverse <rev>..<rev>]
14                   [--] <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       -h
208           Show help message.
209
210       -c
211           Use the same output mode as git-annotate(1) (Default: off).
212
213       --score-debug
214           Include debugging information related to the movement of lines
215           between files (see -C) and lines moved within a file (see -M). The
216           first number listed is the score. This is the number of
217           alphanumeric characters detected as having been moved between or
218           within files. This must be above a certain threshold for git blame
219           to consider those lines of code to have been moved.
220
221       -f, --show-name
222           Show the filename in the original commit. By default the filename
223           is shown if there is any line that came from a file with a
224           different name, due to rename detection.
225
226       -n, --show-number
227           Show the line number in the original commit (Default: off).
228
229       -s
230           Suppress the author name and timestamp from the output.
231
232       -e, --show-email
233           Show the author email instead of author name (Default: off). This
234           can also be controlled via the blame.showEmail config option.
235
236       -w
237           Ignore whitespace when comparing the parent’s version and the
238           child’s to find where the lines came from.
239
240       --abbrev=<n>
241           Instead of using the default 7+1 hexadecimal digits as the
242           abbreviated object name, use <m>+1 digits, where <m> is at least
243           <n> but ensures the commit object names are unique. Note that 1
244           column is used for a caret to mark the boundary commit.
245

THE PORCELAIN FORMAT

247       In this format, each line is output after a header; the header at the
248       minimum has the first line which has:
249
250       ·   40-byte SHA-1 of the commit the line is attributed to;
251
252       ·   the line number of the line in the original file;
253
254       ·   the line number of the line in the final file;
255
256       ·   on a line that starts a group of lines from a different commit than
257           the previous one, the number of lines in this group. On subsequent
258           lines this field is absent.
259
260       This header line is followed by the following information at least once
261       for each commit:
262
263       ·   the author name ("author"), email ("author-mail"), time
264           ("author-time"), and time zone ("author-tz"); similarly for
265           committer.
266
267       ·   the filename in the commit that the line is attributed to.
268
269       ·   the first line of the commit log message ("summary").
270
271       The contents of the actual line is output after the above header,
272       prefixed by a TAB. This is to allow adding more header elements later.
273
274       The porcelain format generally suppresses commit information that has
275       already been seen. For example, two lines that are blamed to the same
276       commit will both be shown, but the details for that commit will be
277       shown only once. This is more efficient, but may require more state be
278       kept by the reader. The --line-porcelain option can be used to output
279       full commit information for each line, allowing simpler (but less
280       efficient) usage like:
281
282           # count the number of lines attributed to each author
283           git blame --line-porcelain file |
284           sed -n 's/^author //p' |
285           sort | uniq -c | sort -rn
286

SPECIFYING RANGES

288       Unlike git blame and git annotate in older versions of git, the extent
289       of the annotation can be limited to both line ranges and revision
290       ranges. The -L option, which limits annotation to a range of lines, may
291       be specified multiple times.
292
293       When you are interested in finding the origin for lines 40-60 for file
294       foo, you can use the -L option like so (they mean the same thing — both
295       ask for 21 lines starting at line 40):
296
297           git blame -L 40,60 foo
298           git blame -L 40,+21 foo
299
300       Also you can use a regular expression to specify the line range:
301
302           git blame -L '/^sub hello {/,/^}$/' foo
303
304       which limits the annotation to the body of the hello subroutine.
305
306       When you are not interested in changes older than version v2.6.18, or
307       changes older than 3 weeks, you can use revision range specifiers
308       similar to git rev-list:
309
310           git blame v2.6.18.. -- foo
311           git blame --since=3.weeks -- foo
312
313       When revision range specifiers are used to limit the annotation, lines
314       that have not changed since the range boundary (either the commit
315       v2.6.18 or the most recent commit that is more than 3 weeks old in the
316       above example) are blamed for that range boundary commit.
317
318       A particularly useful way is to see if an added file has lines created
319       by copy-and-paste from existing files. Sometimes this indicates that
320       the developer was being sloppy and did not refactor the code properly.
321       You can first find the commit that introduced the file with:
322
323           git log --diff-filter=A --pretty=short -- foo
324
325       and then annotate the change between the commit and its parents, using
326       commit^! notation:
327
328           git blame -C -C -f $commit^! -- foo
329

INCREMENTAL OUTPUT

331       When called with --incremental option, the command outputs the result
332       as it is built. The output generally will talk about lines touched by
333       more recent commits first (i.e. the lines will be annotated out of
334       order) and is meant to be used by interactive viewers.
335
336       The output format is similar to the Porcelain format, but it does not
337       contain the actual lines from the file that is being annotated.
338
339        1. Each blame entry always starts with a line of:
340
341               <40-byte hex sha1> <sourceline> <resultline> <num_lines>
342
343           Line numbers count from 1.
344
345        2. The first time that a commit shows up in the stream, it has various
346           other information about it printed out with a one-word tag at the
347           beginning of each line describing the extra commit information
348           (author, email, committer, dates, summary, etc.).
349
350        3. Unlike the Porcelain format, the filename information is always
351           given and terminates the entry:
352
353               "filename" <whitespace-quoted-filename-goes-here>
354
355           and thus it is really quite easy to parse for some line- and
356           word-oriented parser (which should be quite natural for most
357           scripting languages).
358
359               Note
360               For people who do parsing: to make it more robust, just ignore
361               any lines between the first and last one ("<sha1>" and
362               "filename" lines) where you do not recognize the tag words (or
363               care about that particular one) at the beginning of the
364               "extended information" lines. That way, if there is ever added
365               information (like the commit encoding or extended commit
366               commentary), a blame viewer will not care.
367

MAPPING AUTHORS

369       If the file .mailmap exists at the toplevel of the repository, or at
370       the location pointed to by the mailmap.file or mailmap.blob
371       configuration options, it is used to map author and committer names and
372       email addresses to canonical real names and email addresses.
373
374       In the simple form, each line in the file consists of the canonical
375       real name of an author, whitespace, and an email address used in the
376       commit (enclosed by < and >) to map to the name. For example:
377
378           Proper Name <commit@email.xx>
379
380       The more complex forms are:
381
382           <proper@email.xx> <commit@email.xx>
383
384       which allows mailmap to replace only the email part of a commit, and:
385
386           Proper Name <proper@email.xx> <commit@email.xx>
387
388       which allows mailmap to replace both the name and the email of a commit
389       matching the specified commit email address, and:
390
391           Proper Name <proper@email.xx> Commit Name <commit@email.xx>
392
393       which allows mailmap to replace both the name and the email of a commit
394       matching both the specified commit name and email address.
395
396       Example 1: Your history contains commits by two authors, Jane and Joe,
397       whose names appear in the repository under several forms:
398
399           Joe Developer <joe@example.com>
400           Joe R. Developer <joe@example.com>
401           Jane Doe <jane@example.com>
402           Jane Doe <jane@laptop.(none)>
403           Jane D. <jane@desktop.(none)>
404
405       Now suppose that Joe wants his middle name initial used, and Jane
406       prefers her family name fully spelled out. A proper .mailmap file would
407       look like:
408
409           Jane Doe         <jane@desktop.(none)>
410           Joe R. Developer <joe@example.com>
411
412       Note how there is no need for an entry for <jane@laptop.(none)>,
413       because the real name of that author is already correct.
414
415       Example 2: Your repository contains commits from the following authors:
416
417           nick1 <bugs@company.xx>
418           nick2 <bugs@company.xx>
419           nick2 <nick2@company.xx>
420           santa <me@company.xx>
421           claus <me@company.xx>
422           CTO <cto@coompany.xx>
423
424       Then you might want a .mailmap file that looks like:
425
426           <cto@company.xx>                       <cto@coompany.xx>
427           Some Dude <some@dude.xx>         nick1 <bugs@company.xx>
428           Other Author <other@author.xx>   nick2 <bugs@company.xx>
429           Other Author <other@author.xx>         <nick2@company.xx>
430           Santa Claus <santa.claus@northpole.xx> <me@company.xx>
431
432       Use hash # for comments that are either on their own line, or after the
433       email address.
434

SEE ALSO

436       git-annotate(1)
437

GIT

439       Part of the git(1) suite
440
441
442
443Git 2.30.2                        2021-03-08                      GIT-BLAME(1)
Impressum