summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-02-17Merge branch 'ah/stripspace-optstring'Libravatar Junio C Hamano1-1/+1
* ah/stripspace-optstring: stripspace: call U+0020 a "space" instead of a "blank"
2016-02-10Merge branch 'jk/options-cleanup'Libravatar Junio C Hamano7-102/+57
Various clean-ups to the command line option parsing. * jk/options-cleanup: apply, ls-files: simplify "-z" parsing checkout-index: disallow "--no-stage" option checkout-index: handle "--no-index" option checkout-index: handle "--no-prefix" option checkout-index: simplify "-z" option parsing give "nbuf" strbuf a more meaningful name
2016-02-10Merge branch 'cc/untracked'Libravatar Junio C Hamano1-23/+39
Update the untracked cache subsystem and change its primary UI from "git update-index" to "git config". * cc/untracked: t7063: add tests for core.untrackedCache test-dump-untracked-cache: don't modify the untracked cache config: add core.untrackedCache dir: simplify untracked cache "ident" field dir: add remove_untracked_cache() dir: add {new,add}_untracked_cache() update-index: move 'uc' var declaration update-index: add untracked cache notifications update-index: add --test-untracked-cache update-index: use enum for untracked cache options dir: free untracked cache when removing it
2016-02-03Merge branch 'jk/ref-cache-non-repository-optim'Libravatar Junio C Hamano1-25/+1
The underlying machinery used by "ls-files -o" and other commands have been taught not to create empty submodule ref cache for a directory that is not a submodule. This removes a ton of wasted CPU cycles. * jk/ref-cache-non-repository-optim: resolve_gitlink_ref: ignore non-repository paths clean: make is_git_repository a public function
2016-02-03Merge branch 'nd/diff-with-path-params'Libravatar Junio C Hamano2-2/+2
A few options of "git diff" did not work well when the command was run from a subdirectory. * nd/diff-with-path-params: diff: make -O and --output work in subdirectory diff-no-index: do not take a redundant prefix argument
2016-02-03Merge branch 'tg/ls-remote-symref'Libravatar Junio C Hamano1-54/+36
"ls-remote" learned an option to show which branch the remote repository advertises as its primary by pointing its HEAD at. * tg/ls-remote-symref: ls-remote: add support for showing symrefs ls-remote: use parse-options api ls-remote: fix synopsis ls-remote: document --refs option ls-remote: document --quiet option
2016-02-03Merge branch 'tb/ls-files-eol'Libravatar Junio C Hamano1-0/+21
"git ls-files" learned a new "--eol" option to help diagnose end-of-line problems. * tb/ls-files-eol: ls-files: add eol diagnostics
2016-02-03Merge branch 'jk/notes-merge-from-anywhere'Libravatar Junio C Hamano1-1/+1
"git notes merge" used to limit the source of the merged notes tree to somewhere under refs/notes/ hierarchy, which was too limiting when inventing a workflow to exchange notes with remote repositories using remote-tracking notes trees (located in e.g. refs/remote-notes/ or somesuch). * jk/notes-merge-from-anywhere: notes: allow merging from arbitrary references
2016-02-03Merge branch 'jc/peace-with-crlf'Libravatar Junio C Hamano7-8/+8
Many commands that read files that are expected to contain text that is generated (or can be edited) by the end user to control their behaviour (e.g. "git grep -f <filename>") have been updated to be more tolerant to lines that are terminated with CRLF (they used to treat such a line to contain payload that ends with CR, which is usually not what the users expect). * jc/peace-with-crlf: test-sha1-array: read command stream with strbuf_getline() grep: read -f file with strbuf_getline() send-pack: read list of refs with strbuf_getline() column: read lines with strbuf_getline() cat-file: read batch stream with strbuf_getline() transport-helper: read helper response with strbuf_getline() clone/sha1_file: read info/alternates with strbuf_getline() remote.c: read $GIT_DIR/remotes/* with strbuf_getline() ident.c: read /etc/mailname with strbuf_getline() rev-parse: read parseopt spec with strbuf_getline() revision: read --stdin with strbuf_getline() hash-object: read --stdin-paths with strbuf_getline()
2016-02-01Merge branch 'jk/list-tag-2.7-regression'Libravatar Junio C Hamano1-2/+2
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-02-01apply, ls-files: simplify "-z" parsingLibravatar Jeff King2-24/+6
As a short option, we cannot handle negation. Thus a callback handling "unset" is overkill, and we can just use OPT_SET_INT instead to handle setting the option. Anybody who adds "--nul" synonym to this later would need to be careful not to break "--no-nul", which should mean that lines are terminated with LF at the end. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: disallow "--no-stage" optionLibravatar Jeff King1-3/+3
We do not really expect people to use "--no-stage", but if they do, git currently segfaults. We could instead have it undo the effects of a previous "--stage", but this gets tricky around the "to_tempfile" flag. We cannot simply reset it to 0, because we don't know if it was set by a previous "--stage=all" or an explicit "--temp" option. We could solve this by setting a flag and resolving to_tempfile later, but it's not worth the effort. Nobody actually wants to use "--no-stage"; we are just trying to fix a potential segfault here. While we're in the area, let's improve the user-facing messages for this option. The error string should be translatable, and we should give some hint in the "-h" output about what can go in the argument field. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: handle "--no-index" optionLibravatar Jeff King1-24/+10
The parsing of "--index" is done in a callback, but it does not handle an "unset" option. We don't necessarily expect anyone to use this, but the current behavior is to treat it exactly like "--index", which would probably be surprising. Instead, let's just turn it into an OPT_BOOL, and handle it after we're done parsing. This makes "--no-index" just work (it cancels a previous "--index"). As a bonus, this makes the logic easier to follow. The old code opened the index during the option parsing, leaving the reader to wonder if there was some timing issue (there isn't; none of the other options care that we've opened it). And then if we found that "--prefix" had been given, we had to rollback the index. Now we can simply avoid opening it in the first place. Note that it might make more sense for checkout-index to complain when "--index --prefix=foo" is given (rather than silently ignoring "--index"), but since it has been that way since 415e96c ([PATCH] Implement git-checkout-cache -u to update stat information in the cache., 2005-05-15), it's safer to leave it as-is. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: handle "--no-prefix" optionLibravatar Jeff King1-12/+6
We use a custom callback to parse "--prefix", but it does not handle the "unset" case. As a result, passing "--no-prefix" will cause a segfault. We can fix this by switching it to an OPT_STRING, which makes "--no-prefix" counteract a previous "--prefix". Note that this assigns NULL, so we bump our default-case initialization to lower in the main function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: simplify "-z" option parsingLibravatar Jeff King1-10/+2
Now that we act as a simple bool, there's no need to use a custom callback. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01give "nbuf" strbuf a more meaningful nameLibravatar Jeff King5-29/+30
It's a common pattern in our code to read paths from stdin, separated either by newlines or NULs, and unquote as necessary. In each of these five cases we use "nbuf" to temporarily store the unquoted value. Let's give it the more meaningful name "unquoted", which makes it easier to understand the purpose of the variable. While we're at it, let's also static-initialize all of our strbufs. It's not wrong to call strbuf_init, but it increases the cognitive load on the reader, who might wonder "do we sometimes avoid initializing them? why?". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-29stripspace: call U+0020 a "space" instead of a "blank"Libravatar Alex Henrie1-1/+1
I couldn't find any other examples of people referring to this character as a "blank". Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28Merge branch 'jk/shortlog'Libravatar Junio C Hamano1-87/+99
"git shortlog" used to accumulate various pieces of information regardless of what was asked to be shown in the final output. It has been optimized by noticing what need not to be collected (e.g. there is no need to collect the log messages when showing only the number of changes). * jk/shortlog: shortlog: don't warn on empty author shortlog: optimize out useless string list shortlog: optimize out useless "<none>" normalization shortlog: optimize "--summary" mode shortlog: replace hand-parsing of author with pretty-printer shortlog: use strbufs to read from stdin shortlog: match both "Author:" and "author" on stdin
2016-01-28Merge branch 'jc/strbuf-getline'Libravatar Junio C Hamano20-74/+68
The preliminary clean-up for jc/peace-with-crlf topic. * jc/strbuf-getline: strbuf: give strbuf_getline() to the "most text friendly" variant checkout-index: there are only two possible line terminations update-index: there are only two possible line terminations check-ignore: there are only two possible line terminations check-attr: there are only two possible line terminations mktree: there are only two possible line terminations strbuf: introduce strbuf_getline_{lf,nul}() strbuf: make strbuf_getline_crlf() global strbuf: miniscule style fix
2016-01-28Merge branch 'tk/interpret-trailers-in-place'Libravatar Junio C Hamano1-4/+9
"interpret-trailers" has been taught to optionally update a file in place, instead of always writing the result to the standard output. * tk/interpret-trailers-in-place: interpret-trailers: add option for in-place editing trailer: allow to write to files other than stdout
2016-01-27config: add core.untrackedCacheLibravatar Christian Couder1-11/+24
When we know that mtime on directory as given by the environment is usable for the purpose of untracked cache, we may want the untracked cache to be always used without any mtime test or kernel name check being performed. Also when we know that mtime is not usable for the purpose of untracked cache, for example because the repo is shared over a network file system, we may want the untracked-cache to be automatically removed from the index. Allow the user to express such preference by setting the 'core.untrackedCache' configuration variable, which can take 'keep', 'false', or 'true' and default to 'keep'. When read_index_from() is called, it now adds or removes the untracked cache in the index to respect the value of this variable. So it does nothing if the value is `keep` or if the variable is unset; it adds the untracked cache if the value is `true`; and it removes the cache if the value is `false`. `git update-index --[no-|force-]untracked-cache` still adds the untracked cache to, or removes it, from the index, but this shows a warning if it goes against the value of core.untrackedCache, because the next time the index is read the untracked cache will be added or removed if the configuration is set to do so. Also `--untracked-cache` used to check that the underlying operating system and file system change `st_mtime` field of a directory if files are added or deleted in that directory. But because those tests take a long time, `--untracked-cache` no longer performs them. Instead, there is now `--test-untracked-cache` to perform the tests. This change makes `--untracked-cache` the same as `--force-untracked-cache`. This last change is backward incompatible and should be mentioned in the release notes. Helped-by: Duy Nguyen <pclouds@gmail.com> Helped-by: Torsten Bögershausen <tboegi@web.de> Helped-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> read-cache: Duy'sfixup Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26Merge branch 'jk/symbolic-ref'Libravatar Junio C Hamano2-5/+9
The low-level code that is used to create symbolic references has been updated to share more code with the code that deals with normal references. * jk/symbolic-ref: lock_ref_sha1_basic: handle REF_NODEREF with invalid refs lock_ref_sha1_basic: always fill old_oid while holding lock checkout,clone: check return value of create_symref create_symref: write reflog while holding lock create_symref: use existing ref-lock code create_symref: modernize variable names
2016-01-26Merge branch 'ak/format-patch-odir-config'Libravatar Junio C Hamano1-0/+6
"git format-patch" learned to notice format.outputDirectory configuration variable. This allows "-o <dir>" option to be omitted on the command line if you always use the same directory in your workflow. * ak/format-patch-odir-config: format-patch: introduce format.outputDirectory configuration
2016-01-26Merge branch 'js/close-packs-before-gc'Libravatar Junio C Hamano4-0/+5
Many codepaths that run "gc --auto" before exiting kept packfiles mapped and left the file descriptors to them open, which was not friendly to systems that cannot remove files that are open. They now close the packs before doing so. * js/close-packs-before-gc: receive-pack: release pack files before garbage-collecting merge: release pack files before garbage-collecting am: release pack files before garbage-collecting fetch: release pack files before garbage-collecting
2016-01-26Merge branch 'js/pull-rebase-i'Libravatar Junio C Hamano2-5/+14
"git pull --rebase" has been extended to allow invoking "rebase -i". * js/pull-rebase-i: completion: add missing branch.*.rebase values remote: handle the config setting branch.*.rebase=interactive pull: allow interactive rebase with --rebase=interactive
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King1-2/+2
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25dir: add remove_untracked_cache()Libravatar Christian Couder1-5/+1
Factor out code into remove_untracked_cache(), which will be used in a later commit. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25dir: add {new,add}_untracked_cache()Libravatar Christian Couder1-10/+1
Factor out code into new_untracked_cache() and add_untracked_cache(), which will be used in later commits. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25update-index: move 'uc' var declarationLibravatar Christian Couder1-3/+1
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25update-index: add untracked cache notificationsLibravatar Christian Couder1-5/+9
Attempting to flip the untracked-cache feature on for a random index file with cd /random/unrelated/place git --git-dir=/somewhere/else/.git update-index --untracked-cache would not work as you might expect. Because flipping the feature on in the index also records the location of the corresponding working tree (/random/unrelated/place in the above example), when the index is subsequently used to keep track of files in the working tree in /somewhere/else, the feature is disabled. With this patch "git update-index --[test-]untracked-cache" tells the user in which directory tests are performed. This makes it easy to spot any problem. Also in verbose mode, let's tell the user when the cache is enabled or disabled. Helped-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25update-index: add --test-untracked-cacheLibravatar Christian Couder1-0/+5
It is nice to just be able to test if untracked cache is supported without enabling it. Helped-by: David Turner <dturner@twopensource.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25update-index: use enum for untracked cache optionsLibravatar Christian Couder1-5/+13
Helped-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25clean: make is_git_repository a public functionLibravatar Jeff King1-25/+1
We have always had is_git_directory(), for looking at a specific directory to see if it contains a git repo. In 0179ca7 (clean: improve performance when removing lots of directories, 2015-06-15), we added is_git_repository() which checks for a non-bare repository by looking at its ".git" entry. However, the fix in 0179ca7 needs to be applied other places, too. Let's make this new helper globally available. We need to give it a better name, though, to avoid confusion with is_git_directory(). This patch does that, documents both functions with a comment to reduce confusion, and removes the clean-specific references in the comments. Based-on-a-patch-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-21diff: make -O and --output work in subdirectoryLibravatar Duy Nguyen1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-21diff-no-index: do not take a redundant prefix argumentLibravatar Nguyễn Thái Ngọc Duy1-1/+1
Prefix is already set up in "revs". The same prefix should be used for all options parsing. So kill the last argument. This patch does not actually change anything because the only caller does use the same prefix for init_revisions() and diff_no_index(). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-20Merge branch 'tg/grep-no-index-fallback'Libravatar Junio C Hamano1-3/+9
"git grep" by default does not fall back to its "--no-index" behaviour outside a directory under Git's control (otherwise the user may by mistake end up running a huge recursive search); with a new configuration (set in $HOME/.gitconfig--by definition this cannot be set in the config file per project), this safety can be disabled. * tg/grep-no-index-fallback: builtin/grep: add grep.fallbackToNoIndex config t7810: correct --no-index test
2016-01-20Merge branch 'js/fopen-harder'Libravatar Junio C Hamano3-3/+3
Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR (e.g. COMMIT_EDITMSG) that is meant to be left after the command is done. This however did not work well if the repository is set to be shared with core.sharedRepository and the umask of the previous user is tighter. They have been made to work better by calling unlink(2) and retrying after fopen(3) fails with EPERM. * js/fopen-harder: Handle more file writes correctly in shared repos commit: allow editing the commit message even in shared repos
2016-01-20Merge branch 'jk/clang-pedantic'Libravatar Junio C Hamano1-1/+1
A few unportable C construct have been spotted by clang compiler and have been fixed. * jk/clang-pedantic: bswap: add NO_UNALIGNED_LOADS define avoid shifting signed integers 31 bits
2016-01-20Merge branch 'nd/ita-cleanup'Libravatar Junio C Hamano3-7/+2
Paths that have been told the index about with "add -N" are not quite yet in the index, but a few commands behaved as if they already are in a harmful way. * nd/ita-cleanup: grep: make it clear i-t-a entries are ignored add and use a convenience macro ce_intent_to_add() blame: remove obsolete comment
2016-01-20Merge branch 'mh/notes-allow-reading-treeish'Libravatar Junio C Hamano1-13/+16
Some "git notes" operations, e.g. "git log --notes=<note>", should be able to read notes from any tree-ish that is shaped like a notes tree, but the notes infrastructure required that the argument must be a ref under refs/notes/. Loosen it to require a valid ref only when the operation would update the notes (in which case we must have a place to store the updated notes tree, iow, a ref). * mh/notes-allow-reading-treeish: notes: allow treeish expressions as notes ref
2016-01-19ls-remote: add support for showing symrefsLibravatar Thomas Gummerer1-2/+8
Sometimes it's useful to know the main branch of a git repository without actually downloading the repository. This can be done by looking at the symrefs stored in the remote repository. Currently git doesn't provide a simple way to show the symrefs stored on the remote repository, even though the information is available. Add a --symref command line argument to the ls-remote command, which shows the symrefs in the remote repository. While there, replace a literal tab in the format string with \t to make it more obvious to the reader. Suggested-by: pedro rijo <pedrorijo91@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19ls-remote: use parse-options apiLibravatar Thomas Gummerer1-53/+29
Currently ls-remote uses a hand rolled parser for its command line arguments. Use the parse-options api instead of the hand rolled parser to simplify the code and make it easier to add new arguments. In addition this improves the help message. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19ls-remote: document --refs optionLibravatar Thomas Gummerer1-1/+1
The --refs option was originally introduced in 2718ff0 ("Improve git-peek-remote"). The ls-remote command was first documented in 972b6fe ("ls-remote: drop storing operation and add documentation."), but the --refs option was never documented. Fix this. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: don't warn on empty authorLibravatar Jeff King1-8/+0
Git tries to avoid creating a commit with an empty author name or email. However, commits created by older, less strict versions of git may still be in the history. There's not much point in issuing a warning to stderr for an empty author. The user can't do anything about it now, and we are better off to simply include it in the shortlog output as an empty name/email, and let the caller process it however they see fit. Older versions of shortlog differentiated between "author header not present" (which complained) and "author name/email are blank" (which included the empty ident in the output). But since switching to format_commit_message, we complain to stderr about either case (linux.git has a blank author deep in its history which triggers this). We could try to restore the older behavior (complaining only about the missing header), but in retrospect, there's not much point in differentiating these cases. A missing author header is bogus, but as for the "blank" case, the only useful behavior is to add it to the "empty name" collection. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: optimize out useless string listLibravatar Jeff King1-12/+31
If we are in "--summary" mode, then we do not care about the actual list of subject onelines associated with each author. We care only about the number. So rather than store a string-list for each author full of "<none>", let's just keep a count. This drops my best-of-five for "git shortlog -ns HEAD" on linux.git from: real 0m5.194s user 0m5.028s sys 0m0.168s to: real 0m5.057s user 0m4.916s sys 0m0.144s That's about 2.5%. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: optimize out useless "<none>" normalizationLibravatar Jeff King1-29/+34
If we are in --summary mode, we will always pass <none> to insert_one_record, which will then do some normalization (e.g., cutting out "[PATCH]"). There's no point in doing so if we aren't going to use the result anyway. This drops my best-of-five for "git shortlog -ns HEAD" on linux.git from: real 0m5.257s user 0m5.104s sys 0m0.156s to: real 0m5.194s user 0m5.028s sys 0m0.168s That's only 1%, but arguably the result is clearer to read, as we're able to group our variable declarations inside the conditional block. It also opens up further optimization possibilities for future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: optimize "--summary" modeLibravatar Jeff King1-4/+6
If the user asked us only to show counts for each author, rather than the individual summary lines, then there is no point in us generating the summaries only to throw them away. With this patch, I measured the following speedup for "git shortlog -ns HEAD" on linux.git (best-of-five): [before] real 0m5.644s user 0m5.472s sys 0m0.176s [after] real 0m5.257s user 0m5.104s sys 0m0.156s That's only ~7%, but it's so easy to do, there's no good reason not to. We don't have to touch any downstream code, since we already fill in the magic string "<none>" to handle commits without a message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: replace hand-parsing of author with pretty-printerLibravatar Jeff King1-36/+26
When gathering the author and oneline subject for each commit, we hand-parse the commit headers to find the "author" line, and then continue past to the blank line at the end of the header. We can replace this tricky hand-parsing by simply asking the pretty-printer for the relevant items. This also decouples the author and oneline parsing, opening up some new optimizations in further commits. One reason to avoid the pretty-printer is that it might be less efficient than hand-parsing. However, I measured no slowdown at all running "git shortlog -ns HEAD" on linux.git. As a bonus, we also fix a memory leak in the (uncommon) case that the author field is blank. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: use strbufs to read from stdinLibravatar Jeff King1-9/+12
We currently use fixed-size buffers with fgets(), which could lead to incorrect results in the unlikely event that a line had something like "Author:" at exactly its 1024th character. But it's easy to convert this to a strbuf, and because we can reuse the same buffer through the loop, we don't even pay the extra allocation cost. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-19shortlog: match both "Author:" and "author" on stdinLibravatar Jeff King1-3/+4
The original git-shortlog could read both the normal "git log" output as well as "git log --format=raw". However, when it was converted to C by b8ec592 (Build in shortlog, 2006-10-22), the trailing colon became mandatory, and we no longer matched the raw output. Given the amount of intervening time without any bug reports, it's probable that nobody cares. But it's relatively easy to fix, and the end result is hopefully more readable than the original. Note that this no longer matches "author: ", which we did before, but that has never been a format generated by git. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>