summaryrefslogtreecommitdiff
path: root/builtin/log.c
AgeCommit message (Collapse)AuthorFilesLines
2017-04-11Merge branch 'ah/log-decorate-default-to-auto'Libravatar Junio C Hamano1-1/+8
The default behaviour of "git log" in an interactive session has been changed to enable "--decorate". * ah/log-decorate-default-to-auto: log: if --decorate is not given, default to --decorate=auto
2017-03-24log: if --decorate is not given, default to --decorate=autoLibravatar Alex Henrie1-1/+8
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21prefix_filename: return newly allocated stringLibravatar Jeff King1-1/+1
The prefix_filename() function returns a pointer to static storage, which makes it easy to use dangerously. We already fixed one buggy caller in hash-object recently, and the calls in apply.c are suspicious (I didn't dig in enough to confirm that there is a bug, but we call the function once in apply_all_patches() and then again indirectly from parse_chunk()). Let's make it harder to get wrong by allocating the return value. For simplicity, we'll do this even when the prefix is empty (and we could just return the original file pointer). That will cause us to allocate sometimes when we wouldn't otherwise need to, but this function isn't called in performance critical code-paths (and it already _might_ allocate on any given call, so a caller that cares about performance is questionable anyway). The downside is that the callers need to remember to free() the result to avoid leaking. Most of them already used xstrdup() on the result, so we know they are OK. The remainder have been converted to use free() as appropriate. I considered retaining a prefix_filename_unsafe() for cases where we know the static lifetime is OK (and handling the cleanup is awkward). This is only a handful of cases, though, and it's not worth the mental energy in worrying about whether the "unsafe" variant is OK to use in any situation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21prefix_filename: drop length parameterLibravatar Jeff King1-2/+1
This function takes the prefix as a ptr/len pair, but in every caller the length is exactly strlen(ptr). Let's simplify the interface and just take the string. This saves callers specifying it (and in some cases handling a NULL prefix). In a handful of cases we had the length already without calling strlen, so this is technically slower. But it's not likely to matter (after all, if the prefix is non-empty we'll allocate and copy it into a buffer anyway). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-01pretty: use fmt_output_email_subject()Libravatar René Scharfe1-2/+3
Add the email-style subject prefix (e.g. "Subject: [PATCH] ") directly when it's needed instead of letting log_write_email_headers() prepare it in a static buffer in advance. This simplifies storage ownership and code flow. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-26Merge branch 'jt/format-patch-rfc'Libravatar Junio C Hamano1-1/+9
In some projects, it is common to use "[RFC PATCH]" as the subject prefix for a patch meant for discussion rather than application. A new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH" to help the participants of such projects. * jt/format-patch-rfc: format-patch: add "--rfc" for the common case of [RFC PATCH]
2016-09-21Merge branch 'jt/format-patch-base-info-above-sig'Libravatar Junio C Hamano1-3/+3
"git format-patch --base=..." feature that was recently added showed the base commit information after "-- " e-mail signature line, which turned out to be inconvenient. The base information has been moved above the signature line. * jt/format-patch-base-info-above-sig: format-patch: show base info before email signature
2016-09-21format-patch: add "--rfc" for the common case of [RFC PATCH]Libravatar Josh Triplett1-1/+9
Add an alias for --subject-prefix='RFC PATCH', which is used commonly in some development communities to deserve such a short-hand. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-19Merge branch 'bc/object-id'Libravatar Junio C Hamano1-22/+22
The "unsigned char sha1[20]" to "struct object_id" conversion continues. Notable changes in this round includes that ce->sha1, i.e. the object name recorded in the cache_entry, turns into an object_id. It had merge conflicts with a few topics in flight (Christian's "apply.c split", Dscho's "cat-file --filters" and Jeff Hostetler's "status --porcelain-v2"). Extra sets of eyes double-checking for mismerges are highly appreciated. * bc/object-id: builtin/reset: convert to use struct object_id builtin/commit-tree: convert to struct object_id builtin/am: convert to struct object_id refs: add an update_ref_oid function. sha1_name: convert get_sha1_mb to struct object_id builtin/update-index: convert file to struct object_id notes: convert init_notes to use struct object_id builtin/rm: convert to use struct object_id builtin/blame: convert file to use struct object_id Convert read_mmblob to take struct object_id. notes-merge: convert struct notes_merge_pair to struct object_id builtin/checkout: convert some static functions to struct object_id streaming: make stream_blob_to_fd take struct object_id builtin: convert textconv_object to use struct object_id builtin/cat-file: convert some static functions to struct object_id builtin/cat-file: convert struct expand_data to use struct object_id builtin/log: convert some static functions to use struct object_id builtin/blame: convert struct origin to use struct object_id builtin/apply: convert static functions to struct object_id cache: convert struct cache_entry to use struct object_id
2016-09-15format-patch: show base info before email signatureLibravatar Josh Triplett1-3/+3
Any text below the "-- " for the email signature gets treated as part of the signature, and many mail clients will trim it from the quoted text for a reply. Move it above the signature, so people can reply to it more easily. Similarly, when producing the patch as a MIME attachment, the original code placed the base info after the attached part, which would be discarded. Move the base info to the end of the part, still inside the part boundary. Add tests for the exact format of the email signature, and add tests to ensure that the base info appears before the email signature when producing a plain-text output, and that it appears before the part boundary when producing a MIME attachment. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-08Merge branch 'jk/format-patch-number-singleton-patch-with-cover'Libravatar Junio C Hamano1-4/+4
"git format-patch --cover-letter HEAD^" to format a single patch with a separate cover letter now numbers the output as [PATCH 0/1] and [PATCH 1/1] by default. * jk/format-patch-number-singleton-patch-with-cover: format-patch: show 0/1 and 1/1 for singleton patch with cover letter
2016-09-07streaming: make stream_blob_to_fd take struct object_idLibravatar brian m. carlson1-2/+2
Since all of its callers have been updated, modify stream_blob_to_fd to take a struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07builtin: convert textconv_object to use struct object_idLibravatar brian m. carlson1-1/+1
Since all of its callers have been updated, make textconv_object take a struct object_id. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07builtin/log: convert some static functions to use struct object_idLibravatar brian m. carlson1-22/+22
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-23format-patch: show 0/1 and 1/1 for singleton patch with cover letterLibravatar Jacob Keller1-4/+4
Change the default behavior of git-format-patch to generate numbered sequence of 0/1 and 1/1 when generating both a cover-letter and a single patch. This standardizes the cover letter to have 0/N which helps distinguish the cover letter from the patch itself. Since the behavior is easily changed via configuration as well as the use of -n and -N this should be acceptable default behavior. Add tests for the new default behavior. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12Merge branch 'kw/patch-ids-optim'Libravatar Junio C Hamano1-1/+1
When "git rebase" tries to compare set of changes on the updated upstream and our own branch, it computes patch-id for all of these changes and attempts to find matches. This has been optimized by lazily computing the full patch-id (which is expensive) to be compared only for changes that touch the same set of paths. * kw/patch-ids-optim: rebase: avoid computing unnecessary patch IDs patch-ids: add flag to create the diff patch id using header only data patch-ids: replace the seen indicator with a commit pointer patch-ids: stop using a hand-rolled hashmap implementation
2016-08-11rebase: avoid computing unnecessary patch IDsLibravatar Kevin Willford1-1/+1
The `rebase` family of Git commands avoid applying patches that were already integrated upstream. They do that by using the revision walking option that computes the patch IDs of the two sides of the rebase (local-only patches vs upstream-only ones) and skipping those local patches whose patch ID matches one of the upstream ones. In many cases, this causes unnecessary churn, as already the set of paths touched by a given commit would suffice to determine that an upstream patch has no local equivalent. This hurts performance in particular when there are a lot of upstream patches, and/or large ones. Therefore, let's introduce the concept of a "diff-header-only" patch ID, compare those first, and only evaluate the "full" patch ID lazily. Please note that in contrast to the "full" patch IDs, those "diff-header-only" patch IDs are prone to collide with one another, as adjacent commits frequently touch the very same files. Hence we now have to be careful to allow multiple hash entries with the same hash. We accomplish that by using the hashmap_add() function that does not even test for hash collisions. This also allows us to evaluate the full patch ID lazily, i.e. only when we found commits with matching diff-header-only patch IDs. We add a performance test that demonstrates ~1-6% improvement. In practice this will depend on various factors such as how many upstream changes and how big those changes are along with whether file system caches are cold or warm. As Git's test suite has no way of catching performance regressions, we also add a regression test that verifies that the full patch ID computation is skipped when the diff-header-only computation suffices. Signed-off-by: Kevin Willford <kcwillford@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-10Merge branch 'jt/format-patch-from-config'Libravatar Junio C Hamano1-1/+12
"git format-patch" learned format.from configuration variable to specify the default settings for its "--from" option. * jt/format-patch-from-config: format-patch: format.from gives the default for --from
2016-08-01format-patch: format.from gives the default for --fromLibravatar Josh Triplett1-1/+12
This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-19Merge branch 'js/log-to-diffopt-file'Libravatar Junio C Hamano1-39/+48
The commands in the "log/diff" family have had an FILE* pointer in the data structure they pass around for a long time, but some codepaths used to always write to the standard output. As a preparatory step to make "git format-patch" available to the internal callers, these codepaths have been updated to consistently write into that FILE* instead. * js/log-to-diffopt-file: mingw: fix the shortlog --output=<file> test diff: do not color output when --color=auto and --output=<file> is given t4211: ensure that log respects --output=<file> shortlog: respect the --output=<file> setting format-patch: use stdout directly format-patch: avoid freopen() format-patch: explicitly switch off color when writing to files shortlog: support outputting to streams other than stdout graph: respect the diffopt.file setting line-log: respect diffopt's configured output file stream log-tree: respect diffopt's configured output file stream log: prepare log/log-tree to reuse the diffopt.close_file attribute
2016-07-11Merge branch 'mj/log-show-signature-conf'Libravatar Junio C Hamano1-0/+6
"git log" learns log.showSignature configuration variable, and a command line option "--no-show-signature" to countermand it. * mj/log-show-signature-conf: log: add log.showSignature configuration variable log: add "--no-show-signature" command line option t4202: refactor test
2016-07-06Merge branch 'ew/mboxrd-format-am'Libravatar Junio C Hamano1-1/+1
Teach format-patch and mailsplit (hence "am") how a line that happens to begin with "From " in the e-mail message is quoted with ">", so that these lines can be restored to their original shape. * ew/mboxrd-format-am: am: support --patch-format=mboxrd mailsplit: support unescaping mboxrd messages pretty: support "mboxrd" output format
2016-07-06Merge branch 'jk/string-list-static-init'Libravatar Junio C Hamano1-3/+3
Instead of taking advantage of a struct string_list that is allocated with all NULs happens to be STRING_LIST_INIT_NODUP kind, initialize them explicitly as such, to document their behaviour better. * jk/string-list-static-init: use string_list initializer consistently blame,shortlog: don't make local option variables static interpret-trailers: don't duplicate option strings parse_opt_string_list: stop allocating new strings
2016-06-24format-patch: use stdout directlyLibravatar Johannes Schindelin1-5/+1
Earlier, we freopen()ed stdout in order to write patches to files. That forced us to duplicate stdout (naming it "realstdout") because we *still* wanted to be able to report the file names. As we do not abuse stdout that way anymore, we no longer need to duplicate stdout, either. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24format-patch: avoid freopen()Libravatar Johannes Schindelin1-31/+33
We just taught the relevant functions to respect the diffopt.file field, to allow writing somewhere else than stdout. Let's make use of it. Technically, we do not need to avoid that call in a builtin: we assume that builtins (as opposed to library functions) are stand-alone programs that may do with their (global) state. Yet, we want to be able to reuse that code in properly lib-ified code, e.g. when converting scripts into builtins. Further, while we did not *have* to touch the cmd_show() and cmd_cherry() code paths (because they do not want to write anywhere but stdout as of yet), it just makes sense to be consistent, making it easier and safer to move the code later. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24format-patch: explicitly switch off color when writing to filesLibravatar Johannes Schindelin1-0/+2
The --color=auto handling is done by seeing if file descriptor 1 (the standard output) is connected to a terminal. format-patch used freopen() to reuse the standard output stream even when sending its output to an on-disk file, and this check is appropriate. In the next step, however, we will stop reusing "FILE *stdout", and instead start using arbitrary file descriptor obtained by doing an fopen(3) ourselves. The check --color=auto does will become useless, as we no longer are writing to the standard output stream. But then, we do not need to guess to begin with. As argued in the commit message of 7787570c (format-patch: ignore ui.color, 2011-09-13), we do not allow the ui.color setting to affect format-patch's output. The only time, therefore, that we allow color sequences to be written to the output files is when the user specified the --color=always command-line option explicitly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24log: prepare log/log-tree to reuse the diffopt.close_file attributeLibravatar Johannes Schindelin1-3/+12
We are about to teach the log-tree machinery to reuse the diffopt.file field to output to a file stream other than stdout, in line with the diff machinery already writing to diffopt.file. However, we might want to write something after the diff in log_tree_commit() (e.g. with the --show-linear-break option), therefore we must not let the diff machinery close the file (as per diffopt.close_file. This means that log_tree_commit() itself must override the diffopt.close_file flag and close the file, and if log_tree_commit() is called in a loop, the caller is responsible to do the same. Note: format-patch has an `--output-directory` option. Due to the fact that format-patch's options are parsed first, and that the parse-options machinery accepts uniquely abbreviated options, the diff options `--output` (and `-o`) are shadowed. Therefore close_file is not set to 1 so that cmd_format_patch() does *not* need to handle the close_file flag differently, even if it calls log_tree_commit() in a loop. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24log: add log.showSignature configuration variableLibravatar Mehul Jain1-0/+6
Users may want to always use "--show-signature" while using git-log and related commands. When log.showSignature is set to true, git-log and related commands will behave as if "--show-signature" was given to them. Note that this config variable is meant to affect git-log, git-show, git-whatchanged and git-reflog. Other commands like git-format-patch, git-rev-list are not to be affected by this config variable. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13use string_list initializer consistentlyLibravatar Jeff King1-3/+3
There are two types of string_lists: those that own the string memory, and those that don't. You can tell the difference by the strdup_strings flag, and one should use either STRING_LIST_INIT_DUP, or STRING_LIST_INIT_NODUP as an initializer. Historically, the normal all-zeros initialization has corresponded to the NODUP case. Many sites use no initializer at all, and that works as a shorthand for that case. But for a reader of the code, it can be hard to remember which is which. Let's be more explicit and actually have each site declare which type it means to use. This is a fairly mechanical conversion; I assumed each site was correct as-is, and just switched them all to NODUP. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06pretty: support "mboxrd" output formatLibravatar Eric Wong1-1/+1
This output format prevents format-patch output from breaking readers if somebody copy+pasted an mbox into a commit message. Unlike the traditional "mboxo" format, "mboxrd" is designed to be fully-reversible. "mboxrd" also gracefully degrades to showing extra ">" in existing "mboxo" readers. This degradation is preferable to breaking message splitting completely, a problem I've seen in "mboxcl" due to having multiple, non-existent, or inaccurate Content-Length headers. "mboxcl2" is a non-starter since it's inherits the problems of "mboxcl" while being completely incompatible with existing tooling based around mailsplit. ref: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-23Merge branch 'xy/format-patch-base'Libravatar Junio C Hamano1-0/+168
"git format-patch" learned a new "--base" option to record what (public, well-known) commit the original series was built on in its output. * xy/format-patch-base: format-patch: introduce format.useAutoBase configuration format-patch: introduce --base=auto option format-patch: add '--base' option to record base tree info patch-ids: make commit_patch_id() a public helper function
2016-04-26format-patch: introduce format.useAutoBase configurationLibravatar Xiaolong Ye1-6/+11
This allows to record the base commit automatically, it is equivalent to set --base=auto in cmdline. The format.useAutoBase has lower priority than command line option, so if user set format.useAutoBase and pass the command line option in the meantime, base_commit will be the one passed to command line option. Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-26format-patch: introduce --base=auto optionLibravatar Xiaolong Ye1-3/+27
Introduce --base=auto to record the base commit info automatically, the base_commit will be the merge base of tip commit of the upstream branch and revision-range specified in cmdline. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-26format-patch: add '--base' option to record base tree infoLibravatar Xiaolong Ye1-0/+139
Maintainers or third party testers may want to know the exact base tree the patch series applies to. Teach git format-patch a '--base' option to record the base tree info and append it at the end of the first message (either the cover letter or the first patch in the series). The base tree info consists of the "base commit", which is a well-known commit that is part of the stable part of the project history everybody else works off of, and zero or more "prerequisite patches", which are well-known patches in flight that is not yet part of the "base commit" that need to be applied on top of "base commit" in topological order before the patches can be applied. The "base commit" is shown as "base-commit: " followed by the 40-hex of the commit object name. A "prerequisite patch" is shown as "prerequisite-patch-id: " followed by the 40-hex "patch id", which can be obtained by passing the patch through the "git patch-id --stable" command. Imagine that on top of the public commit P, you applied well-known patches X, Y and Z from somebody else, and then built your three-patch series A, B, C, the history would be like: ---P---X---Y---Z---A---B---C With "git format-patch --base=P -3 C" (or variants thereof, e.g. with "--cover-letter" of using "Z..C" instead of "-3 C" to specify the range), the base tree information block is shown at the end of the first message the command outputs (either the first patch, or the cover letter), like this: base-commit: P prerequisite-patch-id: X prerequisite-patch-id: Y prerequisite-patch-id: Z Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-13Merge branch 'lt/pretty-expand-tabs'Libravatar Junio C Hamano1-0/+1
When "git log" shows the log message indented by 4-spaces, the remainder of a line after a HT does not align in the way the author originally intended. The command now expands tabs by default in such a case, and allows the users to override it with a new option, '--no-expand-tabs'. * lt/pretty-expand-tabs: pretty: test --expand-tabs pretty: allow tweaking tabwidth in --expand-tabs pretty: enable --expand-tabs by default for selected pretty formats pretty: expand tabs in indented logs to make things line up properly
2016-03-30pretty: enable --expand-tabs by default for selected pretty formatsLibravatar Junio C Hamano1-0/+1
"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats. Add --no-expand-tabs option to override the new default. The change alone breaks a test in t4201 that runs "git shortlog" on the output from "git log", and expects that the output from "git log" does not do such a tab expansion. Adjust the test to explicitly disable expand-tabs with --no-expand-tabs. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25diff: activate diff.renames by defaultLibravatar Matthieu Moy1-0/+1
Rename detection is a very convenient feature, and new users shouldn't have to dig in the documentation to benefit from it. Potential objections to activating rename detection are that it sometimes fail, and it is sometimes slow. But rename detection is already activated by default in several cases like "git status" and "git merge", so activating diff.renames does not fundamentally change the situation. When the rename detection fails, it now fails consistently between "git diff" and "git status". This setting does not affect plumbing commands, hence well-written scripts will not be affected. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25log: introduce init_log_defaults()Libravatar Matthieu Moy1-5/+10
This is currently a wrapper around init_grep_defaults(), but will allow adding more initialization in further patches. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13format-patch: introduce format.outputDirectory configurationLibravatar Alexander Kuleshov1-0/+6
We can pass -o/--output-directory to the format-patch command to store patches in some place other than the working directory. This patch introduces format.outputDirectory configuration option for same purpose. The case of usage of this configuration option can be convenience to not pass every time -o/--output-directory if an user has pattern to store all patches in the /patches directory for example. The format.outputDirectory has lower priority than command line option, so if user will set format.outputDirectory and pass the command line option, a result will be stored in a directory that passed to command line option. Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Stephen P. Smith <ischis2@cox.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-15format-patch: add an option to suppress commit hashLibravatar brian m. carlson1-0/+5
Oftentimes, patches created by git format-patch will be stored in version control or compared with diff. In these cases, two otherwise identical patches can have different commit hashes, leading to diff noise. Teach git format-patch a --zero-commit option that instead produces an all-zero hash to avoid this diff noise. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-20Remove get_object_hash.Libravatar brian m. carlson1-9/+9
Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Convert struct object to object_idLibravatar brian m. carlson1-9/+9
struct object is one of the major data structures dealing with object IDs. Convert it to use struct object_id instead of an unsigned char array. Convert get_object_hash to refer to the new member as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-11-20Add several uses of get_object_hash.Libravatar brian m. carlson1-9/+9
Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Jeff King <peff@peff.net>
2015-10-05use strbuf_complete to conditionally append slashLibravatar Jeff King1-2/+1
When working with paths in strbufs, we frequently want to ensure that a directory contains a trailing slash before appending to it. We can shorten this code (and make the intent more obvious) by calling strbuf_complete. Most of these cases are trivially identical conversions, but there are two things to note: - in a few cases we did not check that the strbuf is non-empty (which would lead to an out-of-bounds memory access). These were generally not triggerable in practice, either from earlier assertions, or typically because we would have just fed the strbuf to opendir(), which would choke on an empty path. - in a few cases we indexed the buffer with "original_len" or similar, rather than the current sb->len, and it is not immediately obvious from the diff that they are the same. In all of these cases, I manually verified that the strbuf does not change between the assignment and the strbuf_complete call. This does not convert cases which look like: if (sb->len && !is_dir_sep(sb->buf[sb->len - 1])) strbuf_addch(sb, '/'); as those are obviously semantically different. Some of these cases arguably should be doing that, but that is out of scope for this change, which aims purely for cleanup with no behavior change (and at least it will make such sites easier to find and examine in the future, as we can grep for strbuf_complete). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-25builtin/log.c: minor reformatLibravatar Junio C Hamano1-4/+2
Two logical lines that were not overly long was split in the middle, which made them read worse. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-20log: show merge commit when --cc is givenLibravatar Junio C Hamano1-0/+4
We defaulted to ignoring merge diffs because long long ago, in a galaxy far away, we didn't have a great way to show the diffs. The whole "--cc" option goes back to January '06 and commit d8f4790e6fe7 ("diff-tree --cc: denser combined diff output for a merge commit"). And before that option - so for about 8 months - we had no good way to show the diffs of merges in a good dense way. So the whole "don't show diffs for merges by default" actually made a lot of sense originally, because our merge diffs were not very useful. And this was carried forward to this day. "git log --cc" still ignores merge commits, and you need to say "git log -m --cc" to view a sensible rendition of merge and non-merge commits, even with the previous change to make "--cc" imply "-p". Teach "git log" that "--cc" means the user wants to see interesting changes in merge commits by turning "-m" on. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-20log: when --cc is given, default to -p unless told otherwiseLibravatar Junio C Hamano1-0/+4
The "--cc" option to "git log" is clearly a request to show some sort of combined diff (be it --patch or --raw), but traditionally we required the command line to explicitly ask for "git log -p --cc". Teach the command line parser to treat a lone "--cc" as if the user specified "-p --cc". Formats that do ask for other forms of diff output, e.g. "log --raw --cc", are not overriden. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-20log: rename "tweak" helpersLibravatar Junio C Hamano1-5/+6
The revision walking API allows the callers to tweak its configuration at the last minute, immediately after all the revision and pathspec parameters are parsed from the command line but before the default actions are decided based on them, by defining a "tweak" callback function when calling setup_revisions(). Traditionally, this facility was used by "git show" to turn on the patch output "-p" by default when no diff output option (e.g. "--raw" or "-s" to squelch the output altogether) is given on the command line, and further give dense combined diffs "--cc" for merge commits when no option to countermand it (e.g. "-m" to show pairwise patches). Recently, "git log" started using the same facility, but we named the callback function "default_follow_tweak()", as if the only kind of tweaking we would want for "git log" will forever be limited to turning "--follow" on by default when told by a configuration variable. That was myopic. Rename it to more generic name "log_setup_revisions_tweak()", and match the one used by show "show_setup_revisions_tweak()". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'jk/date-mode-format'Libravatar Junio C Hamano1-2/+2
Teach "git log" and friends a new "--date=format:..." option to format timestamps using system's strftime(3). * jk/date-mode-format: strbuf: make strbuf_addftime more robust introduce "format" date-mode convert "enum date_mode" into a struct show-branch: use DATE_RELATIVE instead of magic number
2015-08-03Merge branch 'dt/log-follow-config'Libravatar Junio C Hamano1-0/+16
Add a new configuration variable to enable "--follow" automatically when "git log" is run with one pathspec argument. * dt/log-follow-config: log: add "log.follow" configuration variable