git/log-tree.h, branch v2.34.2

log-tree.h: remove unused function declarations

2021-10-01T21:39:46Z

The init_log_tree_opt() and log_tree_opt_parse() functions were removed in cd2bdc53094 (Common option parsing for "git log --diff" and friends, 2006-04-14), but not their corresponding *.h declaration. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

format-patch: make output filename configurable

2020-11-10T01:44:41Z

For the past 15 years, we've used the hardcoded 64 as the length limit of the filename of the output from the "git format-patch" command. Since the value is shorter than the 80-column terminal, it could grow without line wrapping a bit. At the same time, since the value is longer than half of the 80-column terminal, we could fit two or more of them in "ls" output on such a terminal if we allowed to lower it. Introduce a new command line option --filename-max-length= and a new configuration variable format.filenameMaxLength to override the hardcoded default. While we are at it, remove a check that the name of output directory does not exceed PATH_MAX---this check is pointless in that by the time control reaches the function, the caller would already have done an equivalent of "mkdir -p", so if the system does not like an overly long directory name, the control wouldn't have reached here, and otherwise, we know that the system allowed the output directory to exist. In the worst case, we will get an error when we try to open the output file and handle the error correctly anyway. Signed-off-by: Junio C Hamano

log: add log.excludeDecoration config option

2020-04-16T18:05:48Z

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//* refspace instead of refs//* 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 Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

format-patch: make cover letters always text/plain

2018-05-02T03:55:00Z

When formatting a series of patches using --attach and --cover-letter, the cover letter lacks the closing MIME boundary, violating RFC 2046. Certain clients, such as Thunderbird, discard the message body in such a case. Since the cover letter is just one part and sending it as multipart/mixed is not very useful, always emit it as text/plain, avoiding the boundary problem altogether. Reported-by: Patrick Hemmer Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

log: add option to choose which refs to decorate

2017-11-22T04:18:59Z

When `log --decorate` is used, git will decorate commits with all available refs. While in most cases this may give the desired effect, under some conditions it can lead to excessively verbose output. Introduce two command line options, `--decorate-refs=` and `--decorate-refs-exclude=` to allow the user to select which refs are used in decoration. When "--decorate-refs=" is given, only the refs that match the pattern are used in decoration. The refs that match the pattern when "--decorate-refs-exclude=" is given, are never used in decoration. These options follow the same convention for mixing negative and positive patterns across the system, assuming that the inclusive default is to match all refs available. (1) if there is no positive pattern given, pretend as if an inclusive default positive pattern was given; (2) for each candidate, reject it if it matches no positive pattern, or if it matches any one of the negative patterns. The rules for what is considered a match are slightly different from the rules used elsewhere. Commands like `log --glob` assume a trailing '/*' when glob chars are not present in the pattern. This makes it difficult to specify a single ref. On the other hand, commands like `describe --match --all` allow specifying exact refs, but do not have the convenience of allowing "shorthand refs" like 'refs/heads' or 'heads' to refer to 'refs/heads/*'. The commands introduced in this patch consider a match if: (a) the pattern contains globs chars, and regular pattern matching returns a match. (b) the pattern does not contain glob chars, and ref '' exists, or if ref exists under '/' This allows both behaviours (allowing single refs and shorthand refs) yet remaining compatible with existent commands. Helped-by: Kevin Daudt Helped-by: Junio C Hamano Signed-off-by: Rafael Ascensão Signed-off-by: Junio C Hamano

pretty: use fmt_output_email_subject()

2017-03-01T23:09:17Z

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 Signed-off-by: Junio C Hamano

log-tree: factor out fmt_output_email_subject()

2017-03-01T17:54:42Z

Use a strbuf to store the subject prefix string and move its construction into its own function. This gets rid of two arbitrary length limits and allows the string to be added by callers directly. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'jn/parse-config-slot'

2014-10-20T19:23:48Z

Code cleanup. * jn/parse-config-slot: color_parse: do not mention variable name in error message pass config slots as pointers instead of offsets

pass config slots as pointers instead of offsets

2014-10-14T18:01:05Z

Many config-parsing helpers, like parse_branch_color_slot, take the name of a config variable and an offset to the "slot" name (e.g., "color.branch.plain" is passed along with "13" to effectively pass "plain"). This is leftover from the time that these functions would die() on error, and would want the full variable name for error reporting. These days they do not use the full variable name at all. Passing a single pointer to the slot name is more natural, and lets us more easily adjust the callers to use skip_prefix to avoid manually writing offset numbers. This is effectively a continuation of 9e1a5eb, which did the same for parse_diff_color_slot. This patch covers all of the remaining similar constructs. Signed-off-by: Jonathan Nieder Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

pretty: add %D format specifier

2014-09-18T22:15:21Z

Add a new format specifier, '%D' that is identical in behaviour to '%d', except that it does not include the ' (' prefix or ')' suffix provided by '%d'. Signed-off-by: Harry Jeffery Signed-off-by: Junio C Hamano