summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2017-09-29Merge branch 'rj/no-sign-compare'Libravatar Junio C Hamano1-2/+2
Many codepaths have been updated to squelch -Wsign-compare warnings. * rj/no-sign-compare: ALLOC_GROW: avoid -Wsign-compare warnings cache.h: hex2chr() - avoid -Wsign-compare warnings commit-slab.h: avoid -Wsign-compare warnings git-compat-util.h: xsize_t() - avoid -Wsign-compare warnings
2017-09-29Merge branch 'jt/fast-export-copy-modify-fix'Libravatar Junio C Hamano1-14/+32
"git fast-export" with -M/-C option issued "copy" instruction on a path that is simultaneously modified, which was incorrect. * jt/fast-export-copy-modify-fix: fast-export: do not copy from modified file
2017-09-29Merge branch 'mk/describe-match-with-all'Libravatar Junio C Hamano1-12/+17
"git describe --match <pattern>" has been taught to play well with the "--all" option. * mk/describe-match-with-all: describe: teach --match to handle branches and remotes
2017-09-28Merge branch 'rs/resolve-ref-optional-result'Libravatar Junio C Hamano6-14/+7
Code clean-up. * rs/resolve-ref-optional-result: refs: pass NULL to resolve_ref_unsafe() if hash is not needed refs: pass NULL to refs_resolve_ref_unsafe() if hash is not needed refs: make sha1 output parameter of refs_resolve_ref_unsafe() optional
2017-09-28Merge branch 'jk/fallthrough'Libravatar Junio C Hamano4-1/+4
Many codepaths have been updated to squelch -Wimplicit-fallthrough warnings from Gcc 7 (which is a good code hygiene). * jk/fallthrough: consistently use "fallthrough" comments in switches curl_trace(): eliminate switch fallthrough test-line-buffer: simplify command parsing
2017-09-28Merge branch 'jk/diff-blob'Libravatar Junio C Hamano1-2/+2
"git cat-file --textconv" started segfaulting recently, which has been corrected. * jk/diff-blob: cat-file: handle NULL object_context.path
2017-09-28Merge branch 'jk/describe-omit-some-refs'Libravatar Junio C Hamano1-3/+6
"git describe --match" learned to take multiple patterns in v2.13 series, but the feature ignored the patterns after the first one and did not work at all. This has been fixed. * jk/describe-omit-some-refs: describe: fix matching to actually match all patterns
2017-09-25Merge branch 'ow/rev-parse-is-shallow-repo'Libravatar Junio C Hamano1-0/+5
"git rev-parse" learned "--is-shallow-repository", that is to be used in a way similar to existing "--is-bare-repository" and friends. * ow/rev-parse-is-shallow-repo: rev-parse: rev-parse: add --is-shallow-repository
2017-09-25Merge branch 'aw/gc-lockfile-fscanf-fix'Libravatar Junio C Hamano1-1/+1
"git gc" tries to avoid running two instances at the same time by reading and writing pid/host from and to a lock file; it used to use an incorrect fscanf() format when reading, which has been corrected. * aw/gc-lockfile-fscanf-fix: gc: call fscanf() with %<len>s, not %<len>c, when reading hostname
2017-09-25Merge branch 'ks/help-alias-label'Libravatar Junio C Hamano1-1/+1
"git help co" now says "co is aliased to ...", not "git co is". * ks/help-alias-label: help: change a message to be more precise
2017-09-25Merge branch 'jn/per-repo-object-store-fixes'Libravatar Junio C Hamano1-2/+2
Step #0 of a planned & larger series to make the in-core object store per in-core repository object. * jn/per-repo-object-store-fixes: replace-objects: evaluate replacement refs without using the object store push, fetch: error out for submodule entries not pointing to commits pack: make packed_git_mru global a value instead of a pointer
2017-09-25Merge branch 'jk/write-in-full-fix'Libravatar Junio C Hamano4-5/+4
Many codepaths did not diagnose write failures correctly when disks go full, due to their misuse of write_in_full() helper function, which have been corrected. * jk/write-in-full-fix: read_pack_header: handle signed/unsigned comparison in read result config: flip return value of store_write_*() notes-merge: use ssize_t for write_in_full() return value pkt-line: check write_in_full() errors against "< 0" convert less-trivial versions of "write_in_full() != len" avoid "write_in_full(fd, buf, len) != len" pattern get-tar-commit-id: check write_in_full() return against 0 config: avoid "write_in_full(fd, buf, len) < len" pattern
2017-09-24refs: pass NULL to resolve_ref_unsafe() if hash is not neededLibravatar René Scharfe6-14/+7
This allows us to get rid of some write-only variables, among them seven SHA1 buffers. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22ALLOC_GROW: avoid -Wsign-compare warningsLibravatar Ramsay Jones1-2/+2
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22consistently use "fallthrough" comments in switchesLibravatar Jeff King4-1/+4
Gcc 7 adds -Wimplicit-fallthrough, which can warn when a switch case falls through to the next case. The general idea is that the compiler can't tell if this was intentional or not, so you should annotate any intentional fall-throughs as such, leaving it to complain about any unannotated ones. There's a GNU __attribute__ which can be used for annotation, but of course we'd have to #ifdef it away on non-gcc compilers. Gcc will also recognize specially-formatted comments, which matches our current practice. Let's extend that practice to all of the unannotated sites (which I did look over and verify that they were behaving as intended). Ideally in each case we'd actually give some reasons in the comment about why we're falling through, or what we're falling through to. And gcc does support that with -Wimplicit-fallthrough=2, which relaxes the comment pattern matching to anything that contains "fallthrough" (or a variety of spelling variants). However, this isn't the default for -Wimplicit-fallthrough, nor for -Wextra. In the name of simplicity, it's probably better for us to support the default level, which requires "fallthrough" to be the only thing in the comment (modulo some window dressing like "else" and some punctuation; see the gcc manual for the complete set of patterns). This patch suppresses all warnings due to -Wimplicit-fallthrough. We might eventually want to add that to the DEVELOPER Makefile knob, but we should probably wait until gcc 7 is more widely adopted (since earlier versions will complain about the unknown warning type). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-22cat-file: handle NULL object_context.pathLibravatar Jeff King1-2/+2
Commit dc944b65f1 (get_sha1_with_context: dynamically allocate oc->path, 2017-05-19) changed the rules that callers must follow for seeing if we parsed a path in the object name. The rules switched from "check if the oc.path buffer is empty" to "check if the oc.path pointer is NULL". But that commit forgot to update some sites in cat_one_file(), meaning we might dereference a NULL pointer. You can see this by making a path-aware request like --textconv without specifying --path, and giving an object name that doesn't have a path in it. Like: git cat-file --textconv HEAD which will reliably segfault. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-21fast-export: do not copy from modified fileLibravatar Jonathan Tan1-14/+32
When run with the "-C" option, fast-export writes 'C' commands in its output whenever the internal diff mechanism detects a file copy, indicating that fast-import should copy the given existing file to the given new filename. However, the diff mechanism works against the prior version of the file, whereas fast-import uses whatever is current. This causes issues when a commit both modifies a file and uses it as the source for a copy. Therefore, teach fast-export to refrain from writing 'C' when it has already written a modification command for a file. An existing test in t9350-fast-export is also fixed in this patch. The existing line "C file6 file7" copies the wrong version of file6, but it has coincidentally worked because file7 was subsequently overridden. Reported-by: Juraj Oršulić <juraj.orsulic@fer.hr> Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-20describe: teach --match to handle branches and remotesLibravatar Max Kirillov1-12/+17
When `git describe` uses `--match`, it matches only tags, basically ignoring the `--all` argument even when it is specified. Fix it by also matching branch name and $remote_name/$remote_branch_name, for remote-tracking references, with the specified patterns. Update documentation accordingly and add tests. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-20Merge branch 'jk/describe-omit-some-refs' into mk/describe-match-with-allLibravatar Junio C Hamano1-3/+6
* jk/describe-omit-some-refs: describe: fix matching to actually match all patterns
2017-09-19rev-parse: rev-parse: add --is-shallow-repositoryLibravatar Øystein Walle1-0/+5
Running `git fetch --unshallow` on a repo that is not in fact shallow produces a fatal error message. Add a helper to rev-parse that scripters can use to determine whether a repo is shallow or not. Signed-off-by: Øystein Walle <oystwa@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-19Merge branch 'rk/commit-tree-make-F-verbatim'Libravatar Junio C Hamano1-1/+0
Unlike "git commit-tree < file", "git commit-tree -F file" did not pass the contents of the file verbatim and instead completed an incomplete line at the end, if exists. The latter has been updated to match the behaviour of the former. * rk/commit-tree-make-F-verbatim: commit-tree: do not complete line in -F input
2017-09-19Merge branch 'rs/strbuf-leakfix'Libravatar Junio C Hamano8-20/+45
Many leaks of strbuf have been fixed. * rs/strbuf-leakfix: (34 commits) wt-status: release strbuf after use in wt_longstatus_print_tracking() wt-status: release strbuf after use in read_rebase_todolist() vcs-svn: release strbuf after use in end_revision() utf8: release strbuf on error return in strbuf_utf8_replace() userdiff: release strbuf after use in userdiff_get_textconv() transport-helper: release strbuf after use in process_connect_service() sequencer: release strbuf after use in save_head() shortlog: release strbuf after use in insert_one_record() sha1_file: release strbuf on error return in index_path() send-pack: release strbuf on error return in send_pack() remote: release strbuf after use in set_url() remote: release strbuf after use in migrate_file() remote: release strbuf after use in read_remote_branches() refs: release strbuf on error return in write_pseudoref() notes: release strbuf after use in notes_copy_from_stdin() merge: release strbuf after use in write_merge_heads() merge: release strbuf after use in save_state() mailinfo: release strbuf on error return in handle_boundary() mailinfo: release strbuf after use in handle_from() help: release strbuf on error return in exec_woman_emacs() ...
2017-09-19Merge branch 'jk/shortlog-ident-cleanup'Libravatar Junio C Hamano1-21/+35
Code clean-up. * jk/shortlog-ident-cleanup: shortlog: skip format/parse roundtrip for internal traversal
2017-09-19Merge branch 'sb/merge-commit-msg-hook'Libravatar Junio C Hamano1-0/+8
As "git commit" to conclude a conflicted "git merge" honors the commit-msg hook, "git merge" that recoreds a merge commit that cleanly auto-merges should, but it didn't. * sb/merge-commit-msg-hook: builtin/merge: honor commit-msg hook for merges
2017-09-19Merge branch 'jk/leak-checkers'Libravatar Junio C Hamano8-10/+38
Many of our programs consider that it is OK to release dynamic storage that is used throughout the life of the program by simply exiting, but this makes it harder to leak detection tools to avoid reporting false positives. Plug many existing leaks and introduce a mechanism for developers to mark that the region of memory pointed by a pointer is not lost/leaking to help these tools. * jk/leak-checkers: add UNLEAK annotation for reducing leak false positives set_git_dir: handle feeding gitdir to itself repository: free fields before overwriting them reset: free allocated tree buffers reset: make tree counting less confusing config: plug user_config leak update-index: fix cache entry leak in add_one_file() add: free leaked pathspec after add_files_to_cache() test-lib: set LSAN_OPTIONS to abort by default test-lib: --valgrind should not override --verbose-log
2017-09-19Merge branch 'nm/pull-submodule-recurse-config'Libravatar Junio C Hamano1-2/+6
"git -c submodule.recurse=yes pull" did not work as if the "--recurse-submodules" option was given from the command line. This has been corrected. * nm/pull-submodule-recurse-config: pull: honor submodule.recurse config option pull: fix cli and config option parsing order
2017-09-19Merge branch 'mh/packed-ref-store-prep'Libravatar Junio C Hamano1-2/+2
Fix regression to "gitk --bisect" by a recent update. * mh/packed-ref-store-prep: rev-parse: don't trim bisect refnames
2017-09-19Merge branch 'jh/hashmap-disable-counting'Libravatar Junio C Hamano1-1/+1
Our hashmap implementation in hashmap.[ch] is not thread-safe when adding a new item needs to expand the hashtable by rehashing; add an API to disable the automatic rehashing to work it around. * jh/hashmap-disable-counting: hashmap: add API to disable item counting when threaded
2017-09-19Merge branch 'jk/incore-lockfile-removal'Libravatar Junio C Hamano3-14/+11
The long-standing rule that an in-core lockfile instance, once it is used, must not be freed, has been lifted and the lockfile and tempfile APIs have been updated to reduce the chance of programming errors. * jk/incore-lockfile-removal: stop leaking lock structs in some simple cases ref_lock: stop leaking lock_files lockfile: update lifetime requirements in documentation tempfile: auto-allocate tempfiles on heap tempfile: remove deactivated list entries tempfile: use list.h for linked list tempfile: release deactivated strbufs instead of resetting tempfile: robustify cleanup handler tempfile: factor out deactivation tempfile: factor out activation tempfile: replace die("BUG") with BUG() tempfile: handle NULL tempfile pointers gracefully tempfile: prefer is_tempfile_active to bare access lockfile: do not rollback lock on failed close tempfile: do not delete tempfile on failed close always check return value of close_tempfile verify_signed_buffer: prefer close_tempfile() to close() setup_temporary_shallow: move tempfile struct into function setup_temporary_shallow: avoid using inactive tempfile write_index_as_tree: cleanup tempfile on error
2017-09-19Merge branch 'mg/timestamp-t-fix'Libravatar Junio C Hamano1-1/+1
A mismerge fix. * mg/timestamp-t-fix: name-rev: change ULONG_MAX to TIME_MAX
2017-09-17gc: call fscanf() with %<len>s, not %<len>c, when reading hostnameLibravatar Junio C Hamano1-1/+1
Earlier in this codepath, we (ab)used "%<len>c" to read the hostname recorded in the lockfile into locking_host[HOST_NAME_MAX + 1] while substituting <len> with the actual value of HOST_NAME_MAX. This turns out to be incorrect, as it is an instruction to read exactly the specified number of bytes. Because we are trying to read at most that many bytes, we should be using "%<len>s" instead. Helped-by: A. Wilcox <awilfox@adelielinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-17describe: fix matching to actually match all patternsLibravatar Max Kirillov1-3/+6
`git describe --match` with multiple patterns matches only first pattern. If it fails, next patterns are not tried. Fix it, add test cases and update existing test which has wrong expectation. Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-14avoid "write_in_full(fd, buf, len) != len" patternLibravatar Jeff King3-3/+3
The return value of write_in_full() is either "-1", or the requested number of bytes[1]. If we make a partial write before seeing an error, we still return -1, not a partial value. This goes back to f6aa66cb95 (write_in_full: really write in full or return error on disk full., 2007-01-11). So checking anything except "was the return value negative" is pointless. And there are a couple of reasons not to do so: 1. It can do a funny signed/unsigned comparison. If your "len" is signed (e.g., a size_t) then the compiler will promote the "-1" to its unsigned variant. This works out for "!= len" (unless you really were trying to write the maximum size_t bytes), but is a bug if you check "< len" (an example of which was fixed recently in config.c). We should avoid promoting the mental model that you need to check the length at all, so that new sites are not tempted to copy us. 2. Checking for a negative value is shorter to type, especially when the length is an expression. 3. Linus says so. In d34cf19b89 (Clean up write_in_full() users, 2007-01-11), right after the write_in_full() semantics were changed, he wrote: I really wish every "write_in_full()" user would just check against "<0" now, but this fixes the nasty and stupid ones. Appeals to authority aside, this makes it clear that writing it this way does not have an intentional benefit. It's a historical curiosity that we never bothered to clean up (and which was undoubtedly cargo-culted into new sites). So let's convert these obviously-correct cases (this includes write_str_in_full(), which is just a wrapper for write_in_full()). [1] A careful reader may notice there is one way that write_in_full() can return a different value. If we ask write() to write N bytes and get a return value that is _larger_ than N, we could return a larger total. But besides the fact that this would imply a totally broken version of write(), it would already invoke undefined behavior. Our internal remaining counter is an unsigned size_t, which means that subtracting too many byte will wrap it around to a very large number. So we'll instantly begin reading off the end of the buffer, trying to write gigabytes (or petabytes) of data. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-14get-tar-commit-id: check write_in_full() return against 0Libravatar Jeff King1-2/+1
We ask to write 41 bytes and make sure that the return value is at least 41. This is the same "dangerous" pattern that was fixed in the prior commit (wherein a negative return value is promoted to unsigned), though it is not dangerous here because our "41" is a constant, not an unsigned variable. But we should convert it anyway to avoid modeling a dangerous construct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-14pack: make packed_git_mru global a value instead of a pointerLibravatar Jonathan Nieder1-2/+2
The MRU cache that keeps track of recently used packs is represented using two global variables: struct mru packed_git_mru_storage; struct mru *packed_git_mru = &packed_git_mru_storage; Callers never assign to the packed_git_mru pointer, though, so we can simplify by eliminating it and using &packed_git_mru_storage (renamed to &packed_git_mru) directly. This variable is only used by the packfile subsystem, making this a relatively uninvasive change (and any new unadapted callers would trigger a compile error). Noticed while moving these globals to the object_store struct. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-14help: change a message to be more preciseLibravatar Kaartic Sivaraam1-1/+1
When the user tries to use '--help' option on an aliased command information about the alias is printed as sshown below, $ git co --help `git co' is aliased to `checkout' This doesn't seem correct as the user has aliased only 'co' and not 'git co'. This might even be incorrect in cases in which the user has used an alias like 'tgit'. $ tgit co --help `git co' is aliased to `checkout' So, make the message more precise. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-10Merge branch 'ma/up-to-date'Libravatar Junio C Hamano1-2/+2
Message and doc updates. * ma/up-to-date: treewide: correct several "up-to-date" to "up to date" Documentation/user-manual: update outdated example output
2017-09-10Merge branch 'ma/ts-cleanups'Libravatar Junio C Hamano1-0/+6
Assorted bugfixes and clean-ups. * ma/ts-cleanups: ThreadSanitizer: add suppressions strbuf_setlen: don't write to strbuf_slopbuf pack-objects: take lock before accessing `remaining` convert: always initialize attr_action in convert_attrs
2017-09-10Merge branch 'rs/merge-microcleanup' into maintLibravatar Junio C Hamano1-2/+2
Code clean-up. * rs/merge-microcleanup: merge: use skip_prefix()
2017-09-10Merge branch 'rj/add-chmod-error-message' into maintLibravatar Junio C Hamano1-3/+3
Message fix. * rj/add-chmod-error-message: builtin/add: add detail to a 'cannot chmod' error message
2017-09-10Merge branch 'mg/killed-merge' into maintLibravatar Junio C Hamano1-3/+12
Killing "git merge --edit" before the editor returns control left the repository in a state with MERGE_MSG but without MERGE_HEAD, which incorrectly tells the subsequent "git commit" that there was a squash merge in progress. This has been fixed. * mg/killed-merge: merge: save merge state earlier merge: split write_merge_state in two merge: clarify call chain Documentation/git-merge: explain --continue
2017-09-10Merge branch 'rs/fsck-obj-leakfix' into maintLibravatar Junio C Hamano1-11/+11
Memory leak in an error codepath has been plugged. * rs/fsck-obj-leakfix: fsck: free buffers on error in fsck_obj()
2017-09-10Merge branch 'pw/am-signoff' into maintLibravatar Junio C Hamano1-25/+1
"git am -s" has been taught that some input may end with a trailer block that is not Signed-off-by: and it should refrain from adding an extra blank line before adding a new sign-off in such a case. * pw/am-signoff: am: fix signoff when other trailers are present
2017-09-10Merge branch 'bw/clone-recursive-quiet' into maintLibravatar Junio C Hamano1-0/+3
"git clone --recurse-submodules --quiet" did not pass the quiet option down to submodules. * bw/clone-recursive-quiet: clone: teach recursive clones to respect -q
2017-09-10Merge branch 'pw/sequence-rerere-autoupdate' into maintLibravatar Junio C Hamano2-0/+14
Commands like "git rebase" accepted the --rerere-autoupdate option from the command line, but did not always use it. This has been fixed. * pw/sequence-rerere-autoupdate: cherry-pick/revert: reject --rerere-autoupdate when continuing cherry-pick/revert: remember --rerere-autoupdate t3504: use test_commit rebase -i: honor --rerere-autoupdate rebase: honor --rerere-autoupdate am: remember --rerere-autoupdate setting
2017-09-10Merge branch 'bw/push-options-recursively-to-submodules' into maintLibravatar Junio C Hamano1-9/+40
"git push --recurse-submodules $there HEAD:$target" was not propagated down to the submodules, but now it is. * bw/push-options-recursively-to-submodules: submodule--helper: teach push-check to handle HEAD
2017-09-10Merge branch 'ma/pager-per-subcommand-action' into maintLibravatar Junio C Hamano1-0/+3
The "tag.pager" configuration variable was useless for those who actually create tag objects, as it interfered with the use of an editor. A new mechanism has been introduced for commands to enable pager depending on what operation is being carried out to fix this, and then "git tag -l" is made to run pager by default. If this works out OK, I think there are low-hanging fruits in other commands like "git branch" that outputs long list in one mode while taking input in another. * ma/pager-per-subcommand-action: git.c: ignore pager.* when launching builtin as dashed external tag: change default of `pager.tag` to "on" tag: respect `pager.tag` in list-mode only t7006: add tests for how git tag paginates git.c: provide setup_auto_pager() git.c: let builtins opt for handling `pager.foo` themselves builtin.h: take over documentation from api-builtin.txt
2017-09-10Merge branch 'jk/rev-list-empty-input' into maintLibravatar Junio C Hamano1-1/+2
"git log --tag=no-such-tag" showed log starting from HEAD, which has been fixed---it now shows nothing. * jk/rev-list-empty-input: revision: do not fallback to default when rev_input_given is set rev-list: don't show usage when we see empty ref patterns revision: add rev_input_given flag t6018: flesh out empty input/output rev-list tests
2017-09-10commit-tree: do not complete line in -F inputLibravatar Ross Kabus1-1/+0
"git commit-tree -F <file>", unlike "cat <file> | git commit-tree" (i.e. feeding the same contents from the standard input), added a missing final newline when the input ended in an incomplete line. Correct this inconsistency by leaving the incomplete line as-is, as erring on the side of not touching the input is preferrable and expected for a plumbing command like "commit-tree". Signed-off-by: Ross Kabus <rkabus@aerotech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-09shortlog: skip format/parse roundtrip for internal traversalLibravatar Jeff King1-21/+35
The original git-shortlog command parsed the output of git-log, and the logic went something like this: 1. Read stdin looking for "author" lines. 2. Parse the identity into its name/email bits. 3. Apply mailmap to the name/email. 4. Reformat the identity into a single buffer that is our "key" for grouping entries (either a name by default, or "name <email>" if --email was given). The first part happens in read_from_stdin(), and the other three steps are part of insert_one_record(). When we do an internal traversal, we just swap out the stdin read in step 1 for reading the commit objects ourselves. Prior to 2db6b83d18 (shortlog: replace hand-parsing of author with pretty-printer, 2016-01-18), that made sense; we still had to parse the ident in the commit message. But after that commit, we use pretty.c's "%an <%ae>" to get the author ident (for simplicity). Which means that the pretty printer is doing a parse/format under the hood, and then we parse the result, apply the mailmap, and format the result again. Instead, we can just ask pretty.c to do all of those steps for us (including the mailmap via "%aN <%aE>", and not formatting the address when --email is missing). And then we can push steps 2-4 into read_from_stdin(). This speeds up "git shortlog -ns" on linux.git by about 3%, and eliminates a leak in insert_one_record() of the namemailbuf strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>