summaryrefslogtreecommitdiff
path: root/builtin/log.c
AgeCommit message (Collapse)AuthorFilesLines
2020-12-21diff-merges: handle imply -p on -c/--cc logic for log.cLibravatar Sergey Organov1-4/+0
Move logic that handles implying -p on -c/--cc from log_setup_revisions_tweak() to diff_merges_setup_revs(), where it belongs. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21diff-merges: rename diff_merges_default_to_enable() to match semanticsLibravatar Sergey Organov1-2/+2
Rename diff_merges_default_to_enable() to diff_merges_default_to_first_parent() to match its semantics. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21diff-merges: move checks for first_parent_only out of the moduleLibravatar Sergey Organov1-2/+6
The checks for first_parent_only don't in fact belong to this module, as the primary purpose of this flag is history traversal limiting, so get it out of this module and rename the diff_merges_first_parent_defaults_to_enable() to diff_merges_default_to_enable() to match new semantics. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21diff-merges: rename all functions to have common prefixLibravatar Sergey Organov1-2/+2
Use the same "diff_merges" prefix for all the diff merges function names. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21revision: move diff merges functions to its own diff-merges.cLibravatar Sergey Organov1-0/+1
Create separate diff-merges.c and diff-merges.h files, and move all the code related to handling of diff merges there. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21revision: provide implementation for diff merges tweaksLibravatar Sergey Organov1-11/+2
Use these implementations from show_setup_revisions_tweak() and log_setup_revisions_tweak() in builtin/log.c. This completes moving of management of diff merges parameters to a single place, where we can finally observe them simultaneously. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Merge branch 'jk/format-auto-base-when-able'Libravatar Junio C Hamano1-25/+105
"git format-patch" learns to take "whenAble" as a possible value for the format.useAutoBase configuration variable to become no-op when the automatically computed base does not make sense. * jk/format-auto-base-when-able: format-patch: teach format.useAutoBase "whenAble" option
2020-10-04Merge branch 'jk/shortlog-group-by-trailer'Libravatar Junio C Hamano1-0/+1
"git shortlog" has been taught to group commits by the contents of the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc. * jk/shortlog-group-by-trailer: shortlog: allow multiple groups to be specified shortlog: parse trailer idents shortlog: rename parse_stdin_ident() shortlog: de-duplicate trailer values shortlog: match commit trailers with --group trailer: add interface for iterating over commit trailers shortlog: add grouping option shortlog: change "author" variables to "ident"
2020-10-01format-patch: teach format.useAutoBase "whenAble" optionLibravatar Jacob Keller1-25/+105
The format.useAutoBase configuration option exists to allow users to enable '--base=auto' for format-patch by default. This can sometimes lead to poor workflow, due to unexpected failures when attempting to format an ancient patch: $ git format-patch -1 <an old commit> fatal: base commit shouldn't be in revision list This can be very confusing, as it is not necessarily immediately obvious that the user requested a --base (since this was in the configuration, not on the command line). We do want --base=auto to fail when it cannot provide a suitable base, as it would be equally confusing if a formatted patch did not include the base information when it was requested. Teach format.useAutoBase a new mode, "whenAble". This mode will cause format-patch to attempt to include a base commit when it can. However, if no valid base commit can be found, then format-patch will continue formatting the patch without a base commit. In order to avoid making yet another branch name unusable with --base, do not teach --base=whenAble or --base=whenable. Instead, refactor the base_commit option to use a callback, and rely on the global configuration variable auto_base. This does mean that a user cannot request this optional base commit generation from the command line. However, this is likely not too valuable. If the user requests base information manually, they will be immediately informed of the failure to acquire a suitable base commit. This allows the user to make an informed choice about whether to continue the format. Add tests to cover the new mode of operation for --base. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27shortlog: allow multiple groups to be specifiedLibravatar Jeff King1-0/+1
Now that shortlog supports reading from trailers, it can be useful to combine counts from multiple trailers, or between trailers and authors. This can be done manually by post-processing the output from multiple runs, but it's non-trivial to make sure that each name/commit pair is counted only once. This patch teaches shortlog to accept multiple --group options on the command line, and pull data from all of them. That makes it possible to run: git shortlog -ns --group=author --group=trailer:co-authored-by to get a shortlog that counts authors and co-authors equally. The implementation is mostly straightforward. The "group" enum becomes a bitfield, and the trailer key becomes a list. I didn't bother implementing the multi-group semantics for reading from stdin. It would be possible to do, but the existing matching code makes it awkward, and I doubt anybody cares. The duplicate suppression we used for trailers now covers authors and committers as well (though in non-trailer single-group mode we can skip the hash insertion and lookup, since we only see one value per commit). There is one subtlety: we now care about the case when no group bit is set (in which case we default to showing the author). The caller in builtin/log.c needs to be adapted to ask explicitly for authors, rather than relying on shortlog_init(). It would be possible with some gymnastics to make this keep working as-is, but it's not worth it for a single caller. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-22Merge branch 'es/format-patch-interdiff-cleanup'Libravatar Junio C Hamano1-9/+13
"format-patch --range-diff=<prev> <origin>..HEAD" has been taught not to ignore <origin> when <prev> is a single version. * es/format-patch-interdiff-cleanup: format-patch: use 'origin' as start of current-series-range when known diff-lib: tighten show_interdiff()'s interface diff: move show_interdiff() from its own file to diff-lib
2020-09-09Merge branch 'jt/interpret-branch-name-fallback'Libravatar Junio C Hamano1-1/+1
"git status" has trouble showing where it came from by interpreting reflog entries that recordcertain events, e.g. "checkout @{u}", and gives a hard/fatal error. Even though it inherently is impossible to give a correct answer because the reflog entries lose some information (e.g. "@{u}" does not record what branch the user was on hence which branch 'the upstream' needs to be computed, and even if the record were available, the relationship between branches may have changed), at least hide the error to allow "status" show its output. * jt/interpret-branch-name-fallback: wt-status: tolerate dangling marks refs: move dwim_ref() to header file sha1-name: replace unsigned int with option struct
2020-09-08format-patch: use 'origin' as start of current-series-range when knownLibravatar Eric Sunshine1-7/+11
When formatting a patch series over `origin..HEAD`, one would expect that range to be used as the current-series-range when computing a range-diff between the previous and current versions of a patch series. However, infer_range_diff_ranges() ignores `origin..HEAD` when --range-diff=<prev> specifies a single revision rather than a range, and instead unexpectedly computes the current-series-range based upon <prev>. Address this anomaly by unconditionally using `origin..HEAD` as the current-series-range regardless of <prev> as long as `origin` is known, and only fall back to basing current-series-range on <prev> when `origin` is not known. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-08diff-lib: tighten show_interdiff()'s interfaceLibravatar Eric Sunshine1-1/+2
To compute and show an interdiff, show_interdiff() needs only the two OID's to compare and a diffopts, yet it expects callers to supply an entire rev_info. The demand for rev_info is not only overkill, but also places unnecessary burden on potential future callers which might not otherwise have a rev_info at hand. Address this by tightening its signature to require only the items it needs instead of a full rev_info. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-08diff: move show_interdiff() from its own file to diff-libLibravatar Eric Sunshine1-1/+0
show_interdiff() is a relatively small function and not likely to grow larger or more complicated. Rather than dedicating an entire source file to it, relocate it to diff-lib.c which houses other "take two things and compare them" functions meant to be re-used but not so low-level as to reside in the core diff implementation. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-02wt-status: tolerate dangling marksLibravatar Jonathan Tan1-1/+1
When a user checks out the upstream branch of HEAD, the upstream branch not being a local branch, and then runs "git status", like this: git clone $URL client cd client git checkout @{u} git status no status is printed, but instead an error message: fatal: HEAD does not point to a branch (This error message when running "git branch" persists even after checking out other things - it only stops after checking out a branch.) This is because "git status" reads the reflog when determining the "HEAD detached" message, and thus attempts to DWIM "@{u}", but that doesn't work because HEAD no longer points to a branch. Therefore, when calculating the status of a worktree, tolerate dangling marks. This is done by adding an additional parameter to dwim_ref() and repo_dwim_ref(). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-17Merge branch 'jk/log-fp-implies-m'Libravatar Junio C Hamano1-4/+3
"git log --first-parent -p" showed patches only for single-parent commits on the first-parent chain; the "--first-parent" option has been made to imply "-m". Use "--no-diff-merges" to restore the previous behaviour to omit patches for merge commits. * jk/log-fp-implies-m: doc/git-log: clarify handling of merge commit diffs doc/git-log: move "-t" into diff-options list doc/git-log: drop "-r" diff option doc/git-log: move "Diff Formatting" from rev-list-options log: enable "-m" automatically with "--first-parent" revision: add "--no-diff-merges" option to counteract "-m" log: drop "--cc implies -m" logic
2020-07-29log: enable "-m" automatically with "--first-parent"Libravatar Jeff King1-0/+3
When using "--first-parent" to consider history as a single line of commits, git-log still defaults to treating merges specially, even though they could be considered as single commits in the linearized history (that just introduce all of the changes from the second and higher parents). Let's instead have "--first-parent" imply "-m", which makes something like: git log --first-parent -p do what you'd expect. Likewise: git log --first-parent -Sfoo will find "foo" in merge commits. No new test is needed; we'll tweak the output of the existing "--first-parent -p" test, which now matches the "-m --first-parent -p" test. The unchanged existing test for "--no-diff-merges" confirms that the user can get the old behavior if they want. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29revision: add "--no-diff-merges" option to counteract "-m"Libravatar Jeff King1-2/+2
The "-m" option sets revs->ignore_merges to "0", but there's no way to undo it. This probably isn't something anybody overly cares about, since "1" is already the default, but it will serve as an escape hatch when we flip the default for ignore_merges to "0" in more situations. We'll also add a few extra niceties: - initialize the value to "-1" to indicate "not set", and then resolve it to the normal 0/1 bool in setup_revisions(). This lets any tweak functions, as well as setup_revisions() itself, avoid clobbering the user's preference (which until now they couldn't actually express). - since we now have --no-diff-merges, let's add the matching --diff-merges, which is just a synonym for "-m". Then we don't even need to document --no-diff-merges separately; it countermands the long form of "-m" in the usual way. The new test shows that this behaves just the same as the current behavior without "-m". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-29log: drop "--cc implies -m" logicLibravatar Jeff King1-4/+0
This was added by 82dee4160c (log: show merge commit when --cc is given, 2015-08-20), which explains why we need it. But that commit failed to notice that setup_revisions() already does the same thing, since cd2bdc5309 (Common option parsing for "git log --diff" and friends, 2006-04-14). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28strvec: convert builtin/ callers away from argv_array nameLibravatar Jeff King1-6/+6
We eventually want to drop the argv_array name and just use strvec consistently. There's no particular reason we have to do it all at once, or care about interactions between converted and unconverted bits. Because of our preprocessor compat layer, the names are interchangeable to the compiler (so even a definition and declaration using different names is OK). This patch converts all of the files in builtin/ to keep the diff to a manageable size. The conversion was done purely mechanically with: git ls-files '*.c' '*.h' | xargs perl -i -pe ' s/ARGV_ARRAY/STRVEC/g; s/argv_array/strvec/g; ' and then selectively staging files with "git add builtin/". We'll deal with any indentation/style fallouts separately. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05Merge branch 'dl/opt-callback-cleanup'Libravatar Junio C Hamano1-28/+26
Code cleanup. * dl/opt-callback-cleanup: Use OPT_CALLBACK and OPT_CALLBACK_F
2020-04-28Merge branch 'ds/log-exclude-decoration-config'Libravatar Junio C Hamano1-1/+15
The "--decorate-refs" and "--decorate-refs-exclude" options "git log" takes have learned a companion configuration variable log.excludeDecoration that sits at the lowest priority in the family. * ds/log-exclude-decoration-config: log: add log.excludeDecoration config option log-tree: make ref_filter_match() a helper method
2020-04-28Merge branch 'jc/log-no-mailmap'Libravatar Junio C Hamano1-0/+1
"git log" learns "--[no-]mailmap" as a synonym to "--[no-]use-mailmap" * jc/log-no-mailmap: log: give --[no-]use-mailmap a more sensible synonym --[no-]mailmap clone: reorder --recursive/--recurse-submodules parse-options: teach "git cmd -h" to show alias as alias
2020-04-28Use OPT_CALLBACK and OPT_CALLBACK_FLibravatar Denton Liu1-28/+26
In the codebase, there are many options which use OPTION_CALLBACK in a plain ol' struct definition. However, we have the OPT_CALLBACK and OPT_CALLBACK_F macros which are meant to abstract these plain struct definitions away. These macros are useful as they semantically signal to developers that these are just normal callback option with nothing fancy happening. Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or OPT_CALLBACK_F where applicable. The heavy lifting was done using the following (disgusting) shell script: #!/bin/sh do_replacement () { tr '\n' '\r' | sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' | sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' | tr '\r' '\n' } for f in $(git ls-files \*.c) do do_replacement <"$f" >"$f.tmp" mv "$f.tmp" "$f" done The result was manually inspected and then reformatted to match the style of the surrounding code. Finally, using `git grep OPTION_CALLBACK \*.c`, leftover results which were not handled by the script were manually transformed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-16log: add log.excludeDecoration config optionLibravatar Derrick Stolee1-1/+15
In 'git log', the --decorate-refs-exclude option appends a pattern to a string_list. This list is used to prevent showing some refs in the decoration output, or even by --simplify-by-decoration. Users may want to use their refs space to store utility refs that should not appear in the decoration output. For example, Scalar [1] runs a background fetch but places the "new" refs inside the refs/scalar/hidden/<remote>/* refspace instead of refs/<remote>/* to avoid updating remote refs when the user is not looking. However, these "hidden" refs appear during regular 'git log' queries. A similar idea to use "hidden" refs is under consideration for core Git [2]. Add the 'log.excludeDecoration' config option so users can exclude some refs from decorations by default instead of needing to use --decorate-refs-exclude manually. The config value is multi-valued much like the command-line option. The documentation is careful to point out that the config value can be overridden by the --decorate-refs option, even though --decorate-refs-exclude would always "win" over --decorate-refs. Since the 'log.excludeDecoration' takes lower precedence to --decorate-refs, and --decorate-refs-exclude takes higher precedence, the struct decoration_filter needed another field. This led also to new logic in load_ref_decorations() and ref_filter_match(). There are several tests in t4202-log.sh that test the --decorate-refs-(include|exclude) options, so these are extended. Since the expected output is already stored as a file, most tests could simply replace a "--decorate-refs-exclude" option with an in-line config setting. Other tests involve the precedence of the config option compared to command-line options and needed more modification. [1] https://github.com/microsoft/scalar [2] https://lore.kernel.org/git/77b1da5d3063a2404cd750adfe3bb8be9b6c497d.1585946894.git.gitgitgadget@gmail.com/ Helped-by: Junio C Hamano <gister@pobox.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-07format-patch: teach --no-encode-email-headersLibravatar Emma Brooks1-0/+7
When commit subjects or authors have non-ASCII characters, git format-patch Q-encodes them so they can be safely sent over email. However, if the patch transfer method is something other than email (web review tools, sneakernet), this only serves to make the patch metadata harder to read without first applying it (unless you can decode RFC 2047 in your head). git am as well as some email software supports non-Q-encoded mail as described in RFC 6531. Add --[no-]encode-email-headers and format.encodeEmailHeaders to let the user control this behavior. Signed-off-by: Emma Brooks <me@pluvano.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-16log: give --[no-]use-mailmap a more sensible synonym --[no-]mailmapLibravatar Junio C Hamano1-0/+1
The option name "--use-mailmap" looks OK, but it becomes awkward when you have to negate it, i.e. "--no-use-mailmap". I, perhaps with many other users, always try "--no-mailmap" and become unhappy to see it fail. Add an alias "--[no-]mailmap" to remedy this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-25Merge branch 'dl/format-patch-notes-config-fixup'Libravatar Junio C Hamano1-17/+14
"git format-patch" can take a set of configured format.notes values to specify which notes refs to use in the log message part of the output. The behaviour of this was not consistent with multiple --notes command line options, which has been corrected. * dl/format-patch-notes-config-fixup: notes.h: fix typos in comment notes: break set_display_notes() into smaller functions config/format.txt: clarify behavior of multiple format.notes format-patch: move git_config() before repo_init_revisions() format-patch: use --notes behavior for format.notes notes: extract logic into set_display_notes() notes: create init_display_notes() helper notes: rename to load_display_notes()
2019-12-16Merge branch 'dl/rebase-with-autobase'Libravatar Junio C Hamano1-3/+6
"git rebase" did not work well when format.useAutoBase configuration variable is set, which has been corrected. * dl/rebase-with-autobase: rebase: fix format.useAutoBase breakage format-patch: teach --no-base t4014: use test_config() format-patch: fix indentation t3400: demonstrate failure with format.useAutoBase
2019-12-13notes: break set_display_notes() into smaller functionsLibravatar Denton Liu1-1/+6
In 8164c961e1 (format-patch: use --notes behavior for format.notes, 2019-12-09), we introduced set_display_notes() which was a monolithic function with three mutually exclusive branches. Break the function up into three small and simple functions that each are only responsible for one task. This family of functions accepts an `int *show_notes` instead of returning a value suitable for assignment to `show_notes`. This is for two reasons. First of all, this guarantees that the external `show_notes` variable changes in lockstep with the `struct display_notes_opt`. Second, this prompts future developers to be careful about doing something meaningful with this value. In fact, a NULL check is intentionally omitted because causing a segfault here would tell the future developer that they are meant to use the value for something meaningful. One alternative was making the family of functions accept a `struct rev_info *` instead of the `struct display_notes_opt *`, since the former contains the `show_notes` field as well. This does not work because we have to call git_config() before repo_init_revisions(). However, if we had a `struct rev_info`, we'd need to initialize it before it gets assigned values from git_config(). As a result, we break the circular dependency by having standalone `int show_notes` and `struct display_notes_opt notes_opt` variables which temporarily hold values from git_config() until the values are copied over to `rev`. To implement this change, we need to get a pointer to `rev_info::show_notes`. Unfortunately, this is not possible with bitfields and only direct-assignment is possible. Change `rev_info::show_notes` to a non-bitfield int so that we can get its address. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-09format-patch: move git_config() before repo_init_revisions()Libravatar Denton Liu1-4/+7
In 13cdf78094 (format-patch: teach format.notes config option, 2019-05-16), the order in which git_config() and repo_init_revisions() were swapped so that `rev.notes_opt` would be initialized before git_config() was called. This is problematic, however, as git_config() should generally be called before repo_init_revisions(). Break this circular dependency by creating `show_notes` and `notes_opt` which git_config() reads into. Then, copy these values over to `rev.show_notes` and `rev.notes_opt` after repo_init_revisions() is called. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-09format-patch: use --notes behavior for format.notesLibravatar Denton Liu1-12/+1
When we had multiple `format.notes` config values where we had `<ref1>`, `false`, `<ref2>` (in that order), then we would print out the notes for both `<ref1>` and `<ref2>`. This doesn't make sense, however, since we parse the config in a top-down manner and a `false` should be able to override previous configurations, just like how `--no-notes` will override previous `--notes`. Duplicate the logic that handles the `--[no-]notes[=]` option to `format.notes` for consistency. As a result, when parsing the config from top to bottom, `format.notes = true` will behave like `--notes`, `format.notes = <ref>` will behave like `--notes=<ref>` and `format.notes = false` will behave like `--no-notes`. This change isn't strictly backwards compatible but since it is an edge case where a sane user would not mix notes refs with `false` and this feature is relatively new (released only in v2.23.0), this change should be harmless. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-09notes: rename to load_display_notes()Libravatar Denton Liu1-2/+2
According to the function comment, init_display_notes() was supposed to "Load the notes machinery for displaying several notes trees." Rename this function to load_display_notes() so that its use is more accurately represented. This is done because, in a future commit, we will reuse the name init_display_notes(). Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-05format-patch: teach --no-baseLibravatar Denton Liu1-2/+5
If `format.useAutoBase = true`, there was no way to override this from the command-line. Teach the `--no-base` option in format-patch to override `format.useAutoBase`. Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-05format-patch: fix indentationLibravatar Denton Liu1-1/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21format-patch: pass notes configuration to range-diffLibravatar Denton Liu1-1/+23
Since format-patch accepts `--[no-]notes`, one would expect the range-diff generated to also respect the setting. Unfortunately, the range-diff we currently generate only uses the default option (which always outputs default notes, even when notes are not being used elsewhere). Pass the notes configuration to range-diff so that it can honor it. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21range-diff: pass through --notes to `git log`Libravatar Denton Liu1-1/+1
When a commit being range-diff'd has a note attached to it, the note will be compared as well. However, if a user has multiple notes refs or if they want to suppress notes from being printed, there is currently no way to do this. Pass through `--[no-]notes[=<ref>]` to the `git log` call so that this option is customizable. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Merge branch 'dl/format-patch-cover-from-desc'Libravatar Junio C Hamano1-33/+92
The branch description ("git branch --edit-description") has been used to fill the body of the cover letters by the format-patch command; this has been enhanced so that the subject can also be filled. * dl/format-patch-cover-from-desc: format-patch: teach --cover-from-description option format-patch: use enum variables format-patch: replace erroneous and condition
2019-10-18Merge branch 'bw/format-patch-o-create-leading-dirs'Libravatar Junio C Hamano1-0/+16
"git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>" not "mkdir -p <outdir>", which is being corrected. * bw/format-patch-o-create-leading-dirs: format-patch: create leading components of output directory
2019-10-16format-patch: teach --cover-from-description optionLibravatar Denton Liu1-20/+75
Before, when format-patch generated a cover letter, only the body would be populated with a branch's description while the subject would be populated with placeholder text. However, users may want to have the subject of their cover letter automatically populated in the same way. Teach format-patch to accept the `--cover-from-description` option and corresponding `format.coverFromDescription` config, allowing users to populate different parts of the cover letter (including the subject now). Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-16format-patch: use enum variablesLibravatar Denton Liu1-13/+17
Before, `thread` and `config_cover_letter` were defined as ints even though they behaved as enums. Define actual enums and change these variables to use these new definitions. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-16format-patch: replace erroneous and conditionLibravatar Denton Liu1-1/+1
Commit 30984ed2e9 (format-patch: support deep threading, 2009-02-19), introduced the following lines: #define THREAD_SHALLOW 1 [...] thread = git_config_bool(var, value) && THREAD_SHALLOW; Since git_config_bool() returns a bool, the trailing `&& THREAD_SHALLOW` is a no-op. Replace this errorneous and condition with a ternary statement so that it is clear what the configured value is when a boolean is given. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-12format-patch: create leading components of output directoryLibravatar Bert Wesarg1-0/+16
'git format-patch -o <outdir>' did an equivalent of 'mkdir <outdir>' not 'mkdir -p <outdir>', which is being corrected. Avoid the usage of 'adjust_shared_perm' on the leading directories which may have security implications. Achieved by temporarily disabling of 'config.sharedRepository' like 'git init' does. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05use get_tagged_oid()Libravatar René Scharfe1-2/+3
Avoid derefencing ->tagged without checking for NULL by using the convenience wrapper for getting the ID of the tagged object. It die()s when encountering a broken tag instead of segfaulting. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02log: really flip the --mailmap defaultLibravatar Junio C Hamano1-5/+2
Update the docs, test the interaction between the new default, configuration and command line option, in addition to actually flipping the default. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-01log: flip the --mailmap default unconditionallyLibravatar Junio C Hamano1-15/+1
It turns out that being cautious to warn against upcoming default change was an unpopular behaviour, and such a care can easily be defeated by distro packagers to render it ineffective anyway. Just flip the default, with only a mention in the release notes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-15log: add warning for unspecified log.mailmap settingLibravatar Ariadne Conill1-2/+24
Based on discussions around changing the log.mailmap default to being enabled, it was decided that a transitional period is required. Accordingly, we announce this transitional period with a warning message. Signed-off-by: Ariadne Conill <ariadne@dereferenced.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-13Merge branch 'dl/format-patch-notes-config'Libravatar Junio C Hamano1-1/+19
"git format-patch" learns a configuration to set the default for its --notes=<ref> option. * dl/format-patch-notes-config: format-patch: teach format.notes config option git-format-patch.txt: document --no-notes option
2019-05-17format-patch: teach format.notes config optionLibravatar Denton Liu1-1/+19
In git-format-patch, notes can be appended with the `--notes` option. However, this must be specified by the user on an invocation-by-invocation basis. If a user is not careful, it's possible that they may forget to include it and generate a patch series without notes. Teach git-format-patch the `format.notes` config option. Its value is a notes ref that will be automatically appended. The special value of "standard" can be used to specify the standard notes. This option is overridable with the `--no-notes` option in case a user wishes not to append notes. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>