1GIT-SHORTLOG(1) Git Manual GIT-SHORTLOG(1)
2
6 git-shortlog - Summarize 'git log' output
7
9 git shortlog [<options>] [<revision range>] [[--] <path>...]
10 git log --pretty=short | git shortlog [<options>]
11
14 Summarizes git log output in a format suitable for inclusion in release
15 announcements. Each commit will be grouped by author and title.
16 Additionally, "[PATCH]" will be stripped from the commit description.
18 If no revisions are passed on the command line and either standard
20 input is not a terminal or there is no current branch, git shortlog
21 will output a summary of the log read from standard input, without
22 reference to the current repository.
23
25 -n, --numbered
26 Sort output according to the number of commits per author instead
27 of author alphabetic order.
28 -s, --summary
30 Suppress commit description and provide a commit count summary
31 only.
32 -e, --email
34 Show the email address of each author.
35 --format[=<format>]
37 Instead of the commit subject, use some other information to
38 describe each commit. <format> can be any string accepted by the
39 --format option of git log, such as * [%h] %s. (See the "PRETTY
40 FORMATS" section of git-log(1).)
41 Each pretty-printed commit will be rewrapped before it is shown.
43 -c, --committer
45 Collect and show committer identities instead of authors.
46 -w[<width>[,<indent1>[,<indent2>]]]
48 Linewrap the output by wrapping each line at width. The first line
49 of each entry is indented by indent1 spaces, and the second and
50 subsequent lines are indented by indent2 spaces. width, indent1,
51 and indent2 default to 76, 6 and 9 respectively.
52 If width is 0 (zero) then indent the lines of the output without
54 wrapping them.
55 <revision range>
57 Show only commits in the specified revision range. When no
58 <revision range> is specified, it defaults to HEAD (i.e. the whole
59 history leading to the current commit). origin..HEAD specifies all
60 the commits reachable from the current commit (i.e. HEAD), but not
61 from origin. For a complete list of ways to spell <revision range>,
62 see the "Specifying Ranges" section of gitrevisions(7).
63 [--] <path>...
65 Consider only commits that are enough to explain how the files that
66 match the specified paths came to be.
67 Paths may need to be prefixed with -- to separate them from options
69 or the revision range, when confusion arises.
70
72 The .mailmap feature is used to coalesce together commits by the same
73 person in the shortlog, where their name and/or email address was
74 spelled differently.
75 If the file .mailmap exists at the toplevel of the repository, or at
77 the location pointed to by the mailmap.file or mailmap.blob
78 configuration options, it is used to map author and committer names and
79 email addresses to canonical real names and email addresses.
80 In the simple form, each line in the file consists of the canonical
82 real name of an author, whitespace, and an email address used in the
83 commit (enclosed by < and >) to map to the name. For example:
84 Proper Name <commit@email.xx>
86 The more complex forms are:
88 <proper@email.xx> <commit@email.xx>
90 which allows mailmap to replace only the email part of a commit, and:
92 Proper Name <proper@email.xx> <commit@email.xx>
94 which allows mailmap to replace both the name and the email of a commit
96 matching the specified commit email address, and:
97 Proper Name <proper@email.xx> Commit Name <commit@email.xx>
99 which allows mailmap to replace both the name and the email of a commit
101 matching both the specified commit name and email address.
102 Example 1: Your history contains commits by two authors, Jane and Joe,
104 whose names appear in the repository under several forms:
105 Joe Developer <joe@example.com>
107 Joe R. Developer <joe@example.com>
108 Jane Doe <jane@example.com>
109 Jane Doe <jane@laptop.(none)>
110 Jane D. <jane@desktop.(none)>
111 Now suppose that Joe wants his middle name initial used, and Jane
114 prefers her family name fully spelled out. A proper .mailmap file would
115 look like:
116 Jane Doe <jane@desktop.(none)>
118 Joe R. Developer <joe@example.com>
119 Note how there is no need for an entry for <jane@laptop.(none)>,
122 because the real name of that author is already correct.
123 Example 2: Your repository contains commits from the following authors:
125 nick1 <bugs@company.xx>
127 nick2 <bugs@company.xx>
128 nick2 <nick2@company.xx>
129 santa <me@company.xx>
130 claus <me@company.xx>
131 CTO <cto@coompany.xx>
132 Then you might want a .mailmap file that looks like:
135 <cto@company.xx> <cto@coompany.xx>
137 Some Dude <some@dude.xx> nick1 <bugs@company.xx>
138 Other Author <other@author.xx> nick2 <bugs@company.xx>
139 Other Author <other@author.xx> <nick2@company.xx>
140 Santa Claus <santa.claus@northpole.xx> <me@company.xx>
141 Use hash # for comments that are either on their own line, or after the
144 email address.
145
147 Part of the git(1) suite
148Git 2.21.0 02/24/2019 GIT-SHORTLOG(1)