| 1 | git-blame(1) |
| 2 | ============ |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-blame - Show what revision and author last modified each line of a file |
| 7 | |
| 8 | SYNOPSIS |
| 9 | -------- |
| 10 | [synopsis] |
| 11 | git blame [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental] |
| 12 | [-L <range>] [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>] |
| 13 | [--ignore-rev <rev>] [--ignore-revs-file <file>] |
| 14 | [--color-lines] [--color-by-age] [--progress] [--abbrev=<n>] |
| 15 | [ --contents <file> ] [<rev> | --reverse <rev>..<rev>] [--] <file> |
| 16 | |
| 17 | DESCRIPTION |
| 18 | ----------- |
| 19 | |
| 20 | Annotates each line in the given file with information from the revision which |
| 21 | last modified the line. Optionally, start annotating from the given revision. |
| 22 | |
| 23 | When specified one or more times, `-L` restricts annotation to the requested |
| 24 | lines. |
| 25 | |
| 26 | The origin of lines is automatically followed across whole-file |
| 27 | renames (currently there is no option to turn the rename-following |
| 28 | off). To follow lines moved from one file to another, or to follow |
| 29 | lines that were copied and pasted from another file, etc., see the |
| 30 | `-C` and `-M` options. |
| 31 | |
| 32 | The report does not tell you anything about lines which have been deleted or |
| 33 | replaced; you need to use a tool such as `git diff` or the "pickaxe" |
| 34 | interface briefly mentioned in the following paragraph. |
| 35 | |
| 36 | Apart from supporting file annotation, Git also supports searching the |
| 37 | development history for when a code snippet occurred in a change. This makes it |
| 38 | possible to track when a code snippet was added to a file, moved or copied |
| 39 | between files, and eventually deleted or replaced. It works by searching for |
| 40 | a text string in the diff. A small example of the pickaxe interface |
| 41 | that searches for `blame_usage`: |
| 42 | |
| 43 | ----------------------------------------------------------------------------- |
| 44 | $ git log --pretty=oneline -S'blame_usage' |
| 45 | 5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file> |
| 46 | ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output |
| 47 | ----------------------------------------------------------------------------- |
| 48 | |
| 49 | OPTIONS |
| 50 | ------- |
| 51 | include::blame-options.adoc[] |
| 52 | |
| 53 | `-c`:: |
| 54 | Use the same output mode as linkgit:git-annotate[1] (Default: off). |
| 55 | |
| 56 | `--score-debug`:: |
| 57 | Include debugging information related to the movement of |
| 58 | lines between files (see `-C`) and lines moved within a |
| 59 | file (see `-M`). The first number listed is the score. |
| 60 | This is the number of alphanumeric characters detected |
| 61 | as having been moved between or within files. This must be above |
| 62 | a certain threshold for `git blame` to consider those lines |
| 63 | of code to have been moved. |
| 64 | |
| 65 | `-f`:: |
| 66 | `--show-name`:: |
| 67 | Show the filename in the original commit. By default |
| 68 | the filename is shown if there is any line that came from a |
| 69 | file with a different name, due to rename detection. |
| 70 | |
| 71 | `-n`:: |
| 72 | `--show-number`:: |
| 73 | Show the line number in the original commit (Default: off). |
| 74 | |
| 75 | `-s`:: |
| 76 | Suppress the author name and timestamp from the output. |
| 77 | |
| 78 | `-e`:: |
| 79 | `--show-email`:: |
| 80 | Show the author email instead of the author name (Default: off). |
| 81 | This can also be controlled via the `blame.showEmail` config |
| 82 | option. |
| 83 | |
| 84 | `-w`:: |
| 85 | Ignore whitespace when comparing the parent's version and |
| 86 | the child's to find where the lines came from. |
| 87 | |
| 88 | include::diff-algorithm-option.adoc[] |
| 89 | |
| 90 | `--abbrev=<n>`:: |
| 91 | Instead of using the default _7_ hexadecimal digits as the |
| 92 | abbreviated object name, use at least _<n>_ digits, but ensure |
| 93 | the commit object names are unique. |
| 94 | If commits marked with caret (boundary), question mark (ignored) |
| 95 | or asterisk (unblamable) are shown, extend unmarked object names |
| 96 | to align them. |
| 97 | |
| 98 | |
| 99 | THE DEFAULT FORMAT |
| 100 | ------------------ |
| 101 | |
| 102 | When neither `--porcelain` nor `--incremental` option is specified, |
| 103 | `git blame` will output annotation for each line with: |
| 104 | |
| 105 | - abbreviated object name for the commit the line came from; |
| 106 | - author ident (by default the author name and date, unless `-s` or `-e` |
| 107 | is specified); and |
| 108 | - line number |
| 109 | |
| 110 | before the line contents. |
| 111 | |
| 112 | THE PORCELAIN FORMAT |
| 113 | -------------------- |
| 114 | |
| 115 | In this format, each line is output after a header; the |
| 116 | header at the minimum has the first line which has: |
| 117 | |
| 118 | - 40-byte SHA-1 of the commit the line is attributed to; |
| 119 | - the line number of the line in the original file; |
| 120 | - the line number of the line in the final file; |
| 121 | - on a line that starts a group of lines from a different |
| 122 | commit than the previous one, the number of lines in this |
| 123 | group. On subsequent lines this field is absent. |
| 124 | |
| 125 | This header line is followed by the following information |
| 126 | at least once for each commit: |
| 127 | |
| 128 | - the author name (`author`), email (`author-mail`), time |
| 129 | (`author-time`), and time zone (`author-tz`); similarly |
| 130 | for committer. |
| 131 | - the filename in the commit that the line is attributed to. |
| 132 | - the first line of the commit log message (`summary`). |
| 133 | |
| 134 | The contents of the actual line are output after the above |
| 135 | header, prefixed by a _TAB_. This is to allow adding more |
| 136 | header elements later. |
| 137 | |
| 138 | The porcelain format generally suppresses commit information that has |
| 139 | already been seen. For example, two lines that are blamed to the same |
| 140 | commit will both be shown, but the details for that commit will be shown |
| 141 | only once. Information which is specific to individual lines will not be |
| 142 | grouped together, like revs to be marked `ignored` or `unblamable`. This |
| 143 | is more efficient, but may require more state be kept by the reader. The |
| 144 | `--line-porcelain` option can be used to output full commit information |
| 145 | for each line, allowing simpler (but less efficient) usage like: |
| 146 | |
| 147 | # count the number of lines attributed to each author |
| 148 | git blame --line-porcelain file | |
| 149 | sed -n 's/^author //p' | |
| 150 | sort | uniq -c | sort -rn |
| 151 | |
| 152 | |
| 153 | SPECIFYING RANGES |
| 154 | ----------------- |
| 155 | |
| 156 | Unlike `git blame` and `git annotate` in older versions of git, the extent |
| 157 | of the annotation can be limited to both line ranges and revision |
| 158 | ranges. The `-L` option, which limits annotation to a range of lines, may be |
| 159 | specified multiple times. |
| 160 | |
| 161 | When you are interested in finding the origin for |
| 162 | lines 40-60 for file `foo`, you can use the `-L` option like so |
| 163 | (they mean the same thing -- both ask for 21 lines starting at |
| 164 | line 40): |
| 165 | |
| 166 | git blame -L 40,60 foo |
| 167 | git blame -L 40,+21 foo |
| 168 | |
| 169 | Also you can use a regular expression to specify the line range: |
| 170 | |
| 171 | git blame -L '/^sub hello {/,/^}$/' foo |
| 172 | |
| 173 | which limits the annotation to the body of the `hello` subroutine. |
| 174 | |
| 175 | When you are not interested in changes older than version |
| 176 | v2.6.18, or changes older than 3 weeks, you can use revision |
| 177 | range specifiers similar to `git rev-list`: |
| 178 | |
| 179 | git blame v2.6.18.. -- foo |
| 180 | git blame --since=3.weeks -- foo |
| 181 | |
| 182 | When revision range specifiers are used to limit the annotation, |
| 183 | lines that have not changed since the range boundary (either the |
| 184 | commit v2.6.18 or the most recent commit that is more than 3 |
| 185 | weeks old in the above example) are blamed for that range |
| 186 | boundary commit. |
| 187 | |
| 188 | A particularly useful way is to see if an added file has lines |
| 189 | created by copy-and-paste from existing files. Sometimes this |
| 190 | indicates that the developer was being sloppy and did not |
| 191 | refactor the code properly. You can first find the commit that |
| 192 | introduced the file with: |
| 193 | |
| 194 | git log --diff-filter=A --pretty=short -- foo |
| 195 | |
| 196 | and then annotate the change between the commit and its |
| 197 | parents, using `commit^!` notation: |
| 198 | |
| 199 | git blame -C -C -f $commit^! -- foo |
| 200 | |
| 201 | |
| 202 | INCREMENTAL OUTPUT |
| 203 | ------------------ |
| 204 | |
| 205 | When called with `--incremental` option, the command outputs the |
| 206 | result as it is built. The output generally will talk about |
| 207 | lines touched by more recent commits first (i.e. the lines will |
| 208 | be annotated out of order) and is meant to be used by |
| 209 | interactive viewers. |
| 210 | |
| 211 | The output format is similar to the Porcelain format, but it |
| 212 | does not contain the actual lines from the file that is being |
| 213 | annotated. |
| 214 | |
| 215 | . Each blame entry always starts with a line of: |
| 216 | + |
| 217 | [synopsis] |
| 218 | <40-byte-hex-sha1> <sourceline> <resultline> <num-lines> |
| 219 | + |
| 220 | Line numbers count from 1. |
| 221 | |
| 222 | . The first time that a commit shows up in the stream, it has various |
| 223 | other information about it printed out with a one-word tag at the |
| 224 | beginning of each line describing the extra commit information (author, |
| 225 | email, committer, dates, summary, etc.). |
| 226 | |
| 227 | . Unlike the Porcelain format, the filename information is always |
| 228 | given and terminates the entry: |
| 229 | + |
| 230 | [synopsis] |
| 231 | filename <whitespace-quoted-filename-goes-here> |
| 232 | + |
| 233 | and thus it is really quite easy to parse for some line- and word-oriented |
| 234 | parser (which should be quite natural for most scripting languages). |
| 235 | + |
| 236 | [NOTE] |
| 237 | For people who do parsing: to make it more robust, just ignore any |
| 238 | lines between the first and last one (_<40-byte-hex-sha1>_ and `filename` |
| 239 | lines) where you do not recognize the tag words (or care about that particular |
| 240 | one) at the beginning of the "extended information" lines. That way, if |
| 241 | there is ever added information (like the commit encoding or extended |
| 242 | commit commentary), a blame viewer will not care. |
| 243 | |
| 244 | |
| 245 | MAPPING AUTHORS |
| 246 | --------------- |
| 247 | |
| 248 | See linkgit:gitmailmap[5]. |
| 249 | |
| 250 | CONFIGURATION |
| 251 | ------------- |
| 252 | |
| 253 | include::includes/cmd-config-section-all.adoc[] |
| 254 | |
| 255 | include::config/blame.adoc[] |
| 256 | |
| 257 | SEE ALSO |
| 258 | -------- |
| 259 | linkgit:git-annotate[1] |
| 260 | |
| 261 | GIT |
| 262 | --- |
| 263 | Part of the linkgit:git[1] suite |