1GIT-BLAME(1) Git Manual GIT-BLAME(1)
2
6 git-blame - Show what revision and author last modified each line of a
7 file
8
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
18 Annotates each line in the given file with information from the
19 revision which last modified the line. Optionally, start annotating
20 from the given revision.
21 When specified one or more times, -L restricts annotation to the
23 requested lines.
24 The origin of lines is automatically followed across whole-file renames
26 (currently there is no option to turn the rename-following off). To
27 follow lines moved from one file to another, or to follow lines that
28 were copied and pasted from another file, etc., see the -C and -M
29 options.
30 The report does not tell you anything about lines which have been
32 deleted or replaced; you need to use a tool such as git diff or the
33 "pickaxe" interface briefly mentioned in the following paragraph.
34 Apart from supporting file annotation, Git also supports searching the
36 development history for when a code snippet occurred in a change. This
37 makes it possible to track when a code snippet was added to a file,
38 moved or copied between files, and eventually deleted or replaced. It
39 works by searching for a text string in the diff. A small example of
40 the pickaxe interface that searches for blame_usage:
41 $ git log --pretty=oneline -S'blame_usage'
43 5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
44 ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
45
48 -b
49 Show blank SHA-1 for boundary commits. This can also be controlled
50 via the blame.blankboundary config option.
51 --root
53 Do not treat root commits as boundaries. This can also be
54 controlled via the blame.showRoot config option.
55 --show-stats
57 Include additional statistics at the end of blame output.
58 -L <start>,<end>, -L :<funcname>
60 Annotate only the given line range. May be specified multiple
61 times. Overlapping ranges are allowed.
62 <start> and <end> are optional. “-L <start>” or “-L <start>,” spans
64 from <start> to end of file. “-L ,<end>” spans from start of file
65 to <end>.
66 <start> and <end> can take one of these forms:
68 · number
70 If <start> or <end> is a number, it specifies an absolute line
72 number (lines count from 1).
73 · /regex/
75 This form will use the first line matching the given POSIX
77 regex. If <start> is a regex, it will search from the end of
78 the previous -L range, if any, otherwise from the start of
79 file. If <start> is “^/regex/”, it will search from the start
80 of file. If <end> is a regex, it will search starting at the
81 line given by <start>.
82 · +offset or -offset
84 This is only valid for <end> and will specify a number of lines
86 before or after the line given by <start>.
87 If “:<funcname>” is given in place of <start> and <end>, it is a
89 regular expression that denotes the range from the first funcname
90 line that matches <funcname>, up to the next funcname line.
91 “:<funcname>” searches from the end of the previous -L range, if
92 any, otherwise from the start of file. “^:<funcname>” searches from
93 the start of file.
94 -l
96 Show long rev (Default: off).
97 -t
99 Show raw timestamp (Default: off).
100 -S <revs-file>
102 Use revisions from revs-file instead of calling git-rev-list(1).
103 --reverse <rev>..<rev>
105 Walk history forward instead of backward. Instead of showing the
106 revision in which a line appeared, this shows the last revision in
107 which a line has existed. This requires a range of revision like
108 START..END where the path to blame exists in START. git blame
109 --reverse START is taken as git blame --reverse START..HEAD for
110 convenience.
111 -p, --porcelain
113 Show in a format designed for machine consumption.
114 --line-porcelain
116 Show the porcelain format, but output commit information for each
117 line, not just the first time a commit is referenced. Implies
118 --porcelain.
119 --incremental
121 Show the result incrementally in a format designed for machine
122 consumption.
123 --encoding=<encoding>
125 Specifies the encoding used to output author names and commit
126 summaries. Setting it to none makes blame output unconverted data.
127 For more information see the discussion about encoding in the git-
128 log(1) manual page.
129 --contents <file>
131 When <rev> is not specified, the command annotates the changes
132 starting backwards from the working tree copy. This flag makes the
133 command pretend as if the working tree copy has the contents of the
134 named file (specify - to make the command read from the standard
135 input).
136 --date <format>
138 Specifies the format used to output dates. If --date is not
139 provided, the value of the blame.date config variable is used. If
140 the blame.date config variable is also not set, the iso format is
141 used. For supported values, see the discussion of the --date option
142 at git-log(1).
143 --[no-]progress
145 Progress status is reported on the standard error stream by default
146 when it is attached to a terminal. This flag enables progress
147 reporting even if not attached to a terminal. Can’t use --progress
148 together with --porcelain or --incremental.
149 -M[<num>]
151 Detect moved or copied lines within a file. When a commit moves or
152 copies a block of lines (e.g. the original file has A and then B,
153 and the commit changes it to B and then A), the traditional blame
154 algorithm notices only half of the movement and typically blames
155 the lines that were moved up (i.e. B) to the parent and assigns
156 blame to the lines that were moved down (i.e. A) to the child
157 commit. With this option, both groups of lines are blamed on the
158 parent by running extra passes of inspection.
159 <num> is optional but it is the lower bound on the number of
161 alphanumeric characters that Git must detect as moving/copying
162 within a file for it to associate those lines with the parent
163 commit. The default value is 20.
164 -C[<num>]
166 In addition to -M, detect lines moved or copied from other files
167 that were modified in the same commit. This is useful when you
168 reorganize your program and move code around across files. When
169 this option is given twice, the command additionally looks for
170 copies from other files in the commit that creates the file. When
171 this option is given three times, the command additionally looks
172 for copies from other files in any commit.
173 <num> is optional but it is the lower bound on the number of
175 alphanumeric characters that Git must detect as moving/copying
176 between files for it to associate those lines with the parent
177 commit. And the default value is 40. If there are more than one -C
178 options given, the <num> argument of the last -C will take effect.
179 --ignore-rev <rev>
181 Ignore changes made by the revision when assigning blame, as if the
182 change never happened. Lines that were changed or added by an
183 ignored commit will be blamed on the previous commit that changed
184 that line or nearby lines. This option may be specified multiple
185 times to ignore more than one revision. If the
186 blame.markIgnoredLines config option is set, then lines that were
187 changed by an ignored commit and attributed to another commit will
188 be marked with a ? in the blame output. If the
189 blame.markUnblamableLines config option is set, then those lines
190 touched by an ignored commit that we could not attribute to another
191 revision are marked with a *.
192 --ignore-revs-file <file>
194 Ignore revisions listed in file, which must be in the same format
195 as an fsck.skipList. This option may be repeated, and these files
196 will be processed after any files specified with the
197 blame.ignoreRevsFile config option. An empty file name, "", will
198 clear the list of revs from previously processed files.
199 -h
201 Show help message.
202 -c
204 Use the same output mode as git-annotate(1) (Default: off).
205 --score-debug
207 Include debugging information related to the movement of lines
208 between files (see -C) and lines moved within a file (see -M). The
209 first number listed is the score. This is the number of
210 alphanumeric characters detected as having been moved between or
211 within files. This must be above a certain threshold for git blame
212 to consider those lines of code to have been moved.
213 -f, --show-name
215 Show the filename in the original commit. By default the filename
216 is shown if there is any line that came from a file with a
217 different name, due to rename detection.
218 -n, --show-number
220 Show the line number in the original commit (Default: off).
221 -s
223 Suppress the author name and timestamp from the output.
224 -e, --show-email
226 Show the author email instead of author name (Default: off). This
227 can also be controlled via the blame.showEmail config option.
228 -w
230 Ignore whitespace when comparing the parent’s version and the
231 child’s to find where the lines came from.
232 --abbrev=<n>
234 Instead of using the default 7+1 hexadecimal digits as the
235 abbreviated object name, use <n>+1 digits. Note that 1 column is
236 used for a caret to mark the boundary commit.
237
239 In this format, each line is output after a header; the header at the
240 minimum has the first line which has:
241 · 40-byte SHA-1 of the commit the line is attributed to;
243 · the line number of the line in the original file;
245 · the line number of the line in the final file;
247 · on a line that starts a group of lines from a different commit than
249 the previous one, the number of lines in this group. On subsequent
250 lines this field is absent.
251 This header line is followed by the following information at least once
253 for each commit:
254 · the author name ("author"), email ("author-mail"), time
256 ("author-time"), and time zone ("author-tz"); similarly for
257 committer.
258 · the filename in the commit that the line is attributed to.
260 · the first line of the commit log message ("summary").
262 The contents of the actual line is output after the above header,
264 prefixed by a TAB. This is to allow adding more header elements later.
265 The porcelain format generally suppresses commit information that has
267 already been seen. For example, two lines that are blamed to the same
268 commit will both be shown, but the details for that commit will be
269 shown only once. This is more efficient, but may require more state be
270 kept by the reader. The --line-porcelain option can be used to output
271 full commit information for each line, allowing simpler (but less
272 efficient) usage like:
273 # count the number of lines attributed to each author
275 git blame --line-porcelain file |
276 sed -n 's/^author //p' |
277 sort | uniq -c | sort -rn
278
280 Unlike git blame and git annotate in older versions of git, the extent
281 of the annotation can be limited to both line ranges and revision
282 ranges. The -L option, which limits annotation to a range of lines, may
283 be specified multiple times.
284 When you are interested in finding the origin for lines 40-60 for file
286 foo, you can use the -L option like so (they mean the same thing — both
287 ask for 21 lines starting at line 40):
288 git blame -L 40,60 foo
290 git blame -L 40,+21 foo
291 Also you can use a regular expression to specify the line range:
293 git blame -L '/^sub hello {/,/^}$/' foo
295 which limits the annotation to the body of the hello subroutine.
297 When you are not interested in changes older than version v2.6.18, or
299 changes older than 3 weeks, you can use revision range specifiers
300 similar to git rev-list:
301 git blame v2.6.18.. -- foo
303 git blame --since=3.weeks -- foo
304 When revision range specifiers are used to limit the annotation, lines
306 that have not changed since the range boundary (either the commit
307 v2.6.18 or the most recent commit that is more than 3 weeks old in the
308 above example) are blamed for that range boundary commit.
309 A particularly useful way is to see if an added file has lines created
311 by copy-and-paste from existing files. Sometimes this indicates that
312 the developer was being sloppy and did not refactor the code properly.
313 You can first find the commit that introduced the file with:
314 git log --diff-filter=A --pretty=short -- foo
316 and then annotate the change between the commit and its parents, using
318 commit^! notation:
319 git blame -C -C -f $commit^! -- foo
321
323 When called with --incremental option, the command outputs the result
324 as it is built. The output generally will talk about lines touched by
325 more recent commits first (i.e. the lines will be annotated out of
326 order) and is meant to be used by interactive viewers.
327 The output format is similar to the Porcelain format, but it does not
329 contain the actual lines from the file that is being annotated.
330 1. Each blame entry always starts with a line of:
332 <40-byte hex sha1> <sourceline> <resultline> <num_lines>
334 Line numbers count from 1.
336 2. The first time that a commit shows up in the stream, it has various
338 other information about it printed out with a one-word tag at the
339 beginning of each line describing the extra commit information
340 (author, email, committer, dates, summary, etc.).
341 3. Unlike the Porcelain format, the filename information is always
343 given and terminates the entry:
344 "filename" <whitespace-quoted-filename-goes-here>
346 and thus it is really quite easy to parse for some line- and
348 word-oriented parser (which should be quite natural for most
349 scripting languages).
350 Note
352 For people who do parsing: to make it more robust, just ignore
353 any lines between the first and last one ("<sha1>" and
354 "filename" lines) where you do not recognize the tag words (or
355 care about that particular one) at the beginning of the
356 "extended information" lines. That way, if there is ever added
357 information (like the commit encoding or extended commit
358 commentary), a blame viewer will not care.
359
361 If the file .mailmap exists at the toplevel of the repository, or at
362 the location pointed to by the mailmap.file or mailmap.blob
363 configuration options, it is used to map author and committer names and
364 email addresses to canonical real names and email addresses.
365 In the simple form, each line in the file consists of the canonical
367 real name of an author, whitespace, and an email address used in the
368 commit (enclosed by < and >) to map to the name. For example:
369 Proper Name <commit@email.xx>
371 The more complex forms are:
373 <proper@email.xx> <commit@email.xx>
375 which allows mailmap to replace only the email part of a commit, and:
377 Proper Name <proper@email.xx> <commit@email.xx>
379 which allows mailmap to replace both the name and the email of a commit
381 matching the specified commit email address, and:
382 Proper Name <proper@email.xx> Commit Name <commit@email.xx>
384 which allows mailmap to replace both the name and the email of a commit
386 matching both the specified commit name and email address.
387 Example 1: Your history contains commits by two authors, Jane and Joe,
389 whose names appear in the repository under several forms:
390 Joe Developer <joe@example.com>
392 Joe R. Developer <joe@example.com>
393 Jane Doe <jane@example.com>
394 Jane Doe <jane@laptop.(none)>
395 Jane D. <jane@desktop.(none)>
396 Now suppose that Joe wants his middle name initial used, and Jane
399 prefers her family name fully spelled out. A proper .mailmap file would
400 look like:
401 Jane Doe <jane@desktop.(none)>
403 Joe R. Developer <joe@example.com>
404 Note how there is no need for an entry for <jane@laptop.(none)>,
407 because the real name of that author is already correct.
408 Example 2: Your repository contains commits from the following authors:
410 nick1 <bugs@company.xx>
412 nick2 <bugs@company.xx>
413 nick2 <nick2@company.xx>
414 santa <me@company.xx>
415 claus <me@company.xx>
416 CTO <cto@coompany.xx>
417 Then you might want a .mailmap file that looks like:
420 <cto@company.xx> <cto@coompany.xx>
422 Some Dude <some@dude.xx> nick1 <bugs@company.xx>
423 Other Author <other@author.xx> nick2 <bugs@company.xx>
424 Other Author <other@author.xx> <nick2@company.xx>
425 Santa Claus <santa.claus@northpole.xx> <me@company.xx>
426 Use hash # for comments that are either on their own line, or after the
429 email address.
430
432 git-annotate(1)
433
435 Part of the git(1) suite
436Git 2.24.1 12/10/2019 GIT-BLAME(1)