Each pretty-printed commit will be rewrapped before it is shown.148 |
git log --pretty=short | git shortlog [<options>] 96 | git shortlog [<options>] [<revision range>] [[\--] <path>…]97 |
Summarizes git log output in a format suitable for inclusion 105 | in release announcements. Each commit will be grouped by author and title.
106 |Additionally, "[PATCH]" will be stripped from the commit description.
109 |If no revisions are passed on the command line and either standard input 112 | is not a terminal or there is no current branch, git shortlog will 113 | output a summary of the log read from standard input, without 114 | reference to the current repository.
115 |Sort output according to the number of commits per author instead 127 | of author alphabetic order.
128 |Suppress commit description and provide a commit count summary only.
133 |Show the email address of each author.
138 |Instead of the commit subject, use some other information to
142 | describe each commit. <format> can be any string accepted
143 | by the --format option of git log, such as * [%h] %s.
144 | (See the "PRETTY FORMATS" section of git-log[1].)
Each pretty-printed commit will be rewrapped before it is shown.148 |
Collect and show committer identities instead of authors.
155 |Linewrap the output by wrapping each line at width. The first
159 | line of each entry is indented by indent1 spaces, and the second
160 | and subsequent lines are indented by indent2 spaces. width,
161 | indent1, and indent2 default to 76, 6 and 9 respectively.
If width is 0 (zero) then indent the lines of the output without wrapping
164 | them.
Show only commits in the specified revision range. When no
170 | <revision range> is specified, it defaults to HEAD (i.e. the
171 | whole history leading to the current commit). origin..HEAD
172 | specifies all the commits reachable from the current commit
173 | (i.e. HEAD), but not from origin. For a complete list of
174 | ways to spell <revision range>, see the "Specifying Ranges"
175 | section of gitrevisions[7].
Consider only commits that are enough to explain how the files 180 | that match the specified paths came to be.
181 |Paths may need to be prefixed with "-- " to separate them from 183 | options or the revision range, when confusion arises.
184 |The .mailmap feature is used to coalesce together commits by the same
195 | person in the shortlog, where their name and/or email address was
196 | spelled differently.
If the file .mailmap exists at the toplevel of the repository, or at
200 | the location pointed to by the mailmap.file or mailmap.blob
201 | configuration options, it
202 | is used to map author and committer names and email addresses to
203 | canonical real names and email addresses.
In the simple form, each line in the file consists of the canonical 207 | real name of an author, whitespace, and an email address used in the 208 | commit (enclosed by < and >) to map to the name. For example:
209 |Proper Name <commit@email.xx>215 |
The more complex forms are:
221 |<proper@email.xx> <commit@email.xx>227 |
which allows mailmap to replace only the email part of a commit, and:
233 |Proper Name <proper@email.xx> <commit@email.xx>239 |
which allows mailmap to replace both the name and the email of a 245 | commit matching the specified commit email address, and:
246 |Proper Name <proper@email.xx> Commit Name <commit@email.xx>252 |
which allows mailmap to replace both the name and the email of a 258 | commit matching both the specified commit name and email address.
259 |Example 1: Your history contains commits by two authors, Jane 262 | and Joe, whose names appear in the repository under several forms:
263 |Joe Developer <joe@example.com> 267 | Joe R. Developer <joe@example.com> 268 | Jane Doe <jane@example.com> 269 | Jane Doe <jane@laptop.(none)> 270 | Jane D. <jane@desktop.(none)>271 |
Now suppose that Joe wants his middle name initial used, and Jane
275 | prefers her family name fully spelled out. A proper .mailmap file
276 | would look like:
Jane Doe <jane@desktop.(none)> 281 | Joe R. Developer <joe@example.com>282 |
Note how there is no need for an entry for <jane@laptop.(none)>, because the
286 | real name of that author is already correct.
Example 2: Your repository contains commits from the following 290 | authors:
291 |nick1 <bugs@company.xx> 295 | nick2 <bugs@company.xx> 296 | nick2 <nick2@company.xx> 297 | santa <me@company.xx> 298 | claus <me@company.xx> 299 | CTO <cto@coompany.xx>300 |
Then you might want a .mailmap file that looks like:
<cto@company.xx> <cto@coompany.xx> 308 | Some Dude <some@dude.xx> nick1 <bugs@company.xx> 309 | Other Author <other@author.xx> nick2 <bugs@company.xx> 310 | Other Author <other@author.xx> <nick2@company.xx> 311 | Santa Claus <santa.claus@northpole.xx> <me@company.xx>312 |
Use hash # for comments that are either on their own line, or after 316 | the email address.
317 |Part of the git[1] suite
325 |