aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/util/branch.h
diff options
context:
space:
mode:
Diffstat (limited to 'tools/perf/util/branch.h')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-16 05:14:39 +0000
ags. Verified via strace with o_cloexec set to zero. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-17Makefile: allow combining UBSan with other sanitizersRené Scharfe1-1/+6 Multiple sanitizers can be specified as a comma-separated list. Set the flag NO_UNALIGNED_LOADS even if UndefinedBehaviorSanitizer is not the only sanitizer to build with. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-17alias: compare alias name *case-insensitively*Johannes Schindelin2-2/+2 It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Therefore, we must compare the alias name insensitively to the config keys. This fixes a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-17t1300: demonstrate that CamelCased aliases regressedJohannes Schindelin1-0/+7 It is totally legitimate to add CamelCased aliases, but due to the way config keys are compared, the case does not matter. Except that now it does: the alias name is expected to be all lower-case. This is a regression introduced by a9bcf6586d1 (alias: use the early config machinery to expand aliases, 2017-06-14). Noticed by Alejandro Pauly, diagnosed by Kevin Willford. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-16l10n: bg.po: Updated Bulgarian translation (3206t)Alexander Shopov1-3048/+3111 Signed-off-by: Alexander Shopov <ash@kambanaria.org> 2017-07-15l10n: vi.po(3206t): Update Vietnamese translationTran Ngoc Quan1-3013/+3180 Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com> 2017-07-15l10n: git.pot: v2.14.0 round 1 (34 new, 23 removed)Jiang Xin1-2993/+3059 Generate po/git.pot from v2.14.0-rc0 for git v2.14.0 l10n round 1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 2017-07-13Git 2.14-rc0v2.14.0-rc0Junio C Hamano2-5/+13 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: consult want_color() before emitting colorsJeff King6-12/+93 When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13pretty: respect color settings for %C placeholdersJeff King3-45/+84 The color placeholders have traditionally been unconditional, showing colors even when git is not otherwise configured to do so. This was not so bad for their original use, which was on the command-line (and the user could decide at that moment whether to add colors or not). But these days we have configured formats via pretty.*, and those should operate correctly in multiple contexts. In 3082517 (log --format: teach %C(auto,black) to respect color config, 2012-12-17), we gave an extended placeholder that could be used to accomplish this. But it's rather clunky to use, because you have to specify it individually for each color (and their matching resets) in the format. We shied away from just switching the default to auto, because it is technically breaking backwards compatibility. However, there's not really a use case for unconditional colors. The most plausible reason you would want them is to redirect "git log" output to a file. But there, the right answer is --color=always, as it does the right thing both with custom user-format colors and git-generated colors. So let's switch to the more useful default. In the off-chance that somebody really does find a use for unconditional colors without wanting to enable the rest of git's colors, we provide a new %C(always,...) to enable the old behavior. And we can remind them of --color=always in the documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13rev-list: pass diffopt->use_colors through to pretty-printJeff King2-0/+12 When rev-list pretty-prints a commit, it creates a new pretty_print_context and copies items from the rev_info struct. We don't currently copy the "use_color" field, though. Nobody seems to have noticed because the only part of pretty.c that cares is the %C(auto,...) placeholder, and presumably not many people use that with the rev-list plumbing (as opposed to with git-log). It will become more noticeable in a future patch, though, when we start treating all user-format colors as auto-colors (in which case it would become impossible to format colors with rev-list, even with --color=always). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13for-each-ref: load config earlierJeff King1-3/+2 In most commands we load config before parsing command line options, since it lets the latter override the former with a simple variable assignment. In the case of for-each-ref, though, we do it in the reverse order. This is OK with the current code, since there's no interaction between the config and command-line options. However, as the ref-filter code starts to care about config during verify_ref_format(), we'll want to make sure the config is loaded. Let's bump the config to the usual spot near the top of the function. We can drop the comment there; it's impossible to keep a "why we load the config" comment like this up to date with every config option we might be interested in. And indeed, it's already stale; we'd care about core.abbrev, for instance, when %(objectname:short) is used. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13color: check color.ui in git_default_config()Jeff King7-16/+8 Back in prehistoric times, our decision on whether or not to show color by default relied on using a config callback that either did or didn't load color config like color.diff. When we introduced color.ui, we put it in the same boat: commands had to manually respect it by using git_color_config() or its git_color_default_config() convenience wrapper. But in 4c7f1819b (make color.ui default to 'auto', 2013-06-10), that changed. Since then, we default color.ui to auto in all programs, meaning that even plumbing commands like "git diff-tree --pretty" might colorize the output. Nobody seems to have complained in the intervening years, presumably because the "is stdout a tty" check does a good job of catching the right cases. But that leaves an interesting curiosity: color.ui defaults to auto even in plumbing, but you can't actually _disable_ the color via config. So if you really hate color and set "color.ui" to false, diff-tree will still show color (but porcelain like git-diff won't). Nobody noticed that either, probably because very few people disable color. One could argue that the plumbing should _always_ disable color unless an explicit --color option is given on the command line. But in practice, this creates a lot of complications for scripts which do want plumbing to show user-visible output. They can't just pass "--color" blindly; they need to check the user's config and decide what to send. Given that nobody has complained about the current behavior, let's assume it's a good path, and follow it to its conclusion: supporting color.ui everywhere. Note that you can create havoc by setting color.ui=always in your config, but that's more or less already the case. We could disallow it entirely, but it is handy for one-offs like: git -c color.ui=always foo >not-a-tty when "foo" does not take a --color option itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: pass ref_format struct to atom parsersJeff King1-17/+25 The callback for parsing each formatting atom gets to see only the atom struct (which it's filling in) and the text to be parsed. This doesn't leave any room for it to behave differently based on context known only to the ref_format. We can solve this by passing in the surrounding ref_format to each parser. Note that this makes things slightly awkward for sort strings, which parse atoms without having a ref_format. We'll solve that by using a dummy ref_format with default parameters. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: factor out the parsing of sorting atomsJeff King1-4/+8 We parse sort strings as single formatting atoms, and just build on parse_ref_filter_atom(). Let's pull this idea into its own function, since it's about to get a little more complex. As a bonus, we can give the function a slightly more natural interface, since our single atoms are in their own strings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: make parse_ref_filter_atom a private functionJeff King2-3/+1 The parse_ref_filter_atom() function really shouldn't be exposed outside of ref-filter.c; its return value is an integer index into an array that is private in that file. Since the previous commit removed the sole external caller (and replaced it with a public function at a more appropriately level), we can just make this static. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: provide a function for parsing sort optionsJeff King3-30/+11 The ref-filter module currently provides a callback suitable for parsing command-line --sort options. But since git-tag also supports the tag.sort config option, it needs a function whose implementation is quite similar, but with a slightly different interface. The end result is that builtin/tag.c has a copy-paste of parse_opt_ref_sorting(). Instead, let's provide a function to parse an arbitrary sort string, which we can then trivially wrap to make the parse_opt variant. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: move need_color_reset_at_eol into ref_formatJeff King2-4/+6 Calling verify_ref_format() doesn't just confirm that the format is sane; it actually sets some global variables that will be used later when formatting the refs. These logically should belong to the ref_format, which would make it possible to use multiple formats within a single program invocation. Let's move one such flag into the ref_format struct. There are still others that would need to be moved before it would be safe to use multiple formats, but this commit gives a blueprint for how that should look. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: abstract ref format into its own structJeff King6-52/+70 The ref-filter module provides routines for formatting a ref for output. The fundamental interface for the format is a "const char *" containing the format, and any additional options need to be passed to each invocation of show_ref_array_item. Instead, let's make a ref_format struct that holds the format, along with any associated format options. That will make some enhancements easier in the future: 1. new formatting options can be added without disrupting existing callers 2. some state can be carried in the struct rather than as global variables For now this just has the text format itself along with the quote_style option, but we'll add more fields in future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13ref-filter: simplify automatic color resetJeff King1-5/+1 When the user-format doesn't add the closing color reset, we add one automatically. But we do so by parsing the "reset" string. We can just use the baked-in string literal, which is simpler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13t: use test_decode_color rather than literal ANSI codesJeff King4-39/+44 When we put literal ANSI terminal codes into our test scripts, it makes diffs on those scripts hard to read (the colors may be indistinguishable from diff coloring, or in the case of a reset, may not be visible at all). Some scripts get around this by including human-readable names and converting to literal codes with a git-config hack. This makes the actual code diffs look OK, but test_cmp output suffers from the same problem. Let's use test_decode_color instead, which turns the codes into obvious text tags. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13docs/for-each-ref: update pointer to color syntaxJeff King1-2/+4 The documentation for the %(color) placeholder refers to the color.branch.* config for more details. But those details moved to their own section in b92c1a28f (Documentation/config.txt: describe 'color' value type in the "Values" section, 2015-03-03). Let's update our pointer. We can steal the text from 30cfe72d3 (pretty: fix document link for color specification, 2016-10-11), which fixed the same problem in a different place. While we're at it, let's give an example, which makes the syntax much more clear than just the text. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13check return value of verify_ref_format()Jeff King3-5/+10 Users of the ref-filter code must call verify_ref_format() before formatting any refs, but most ignore its return value. This means we may print an error on a syntactically bogus pattern, but keep going anyway. In most cases this results in a fatal error when we actually try to format a ref. But if you have no refs to show at all, then the behavior is confusing: git prints the error from verify_ref_format(), then exits with code 0 without showing any output. Let's instead abort immediately if we know we have a bogus format. We'll output the usage information if we have it handy (just like the existing call in cmd_for_each_ref() does), and otherwise just die(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13git-p4: filter for {'code':'info'} in p4CmdListMiguel Torroja2-5/+8 The function p4CmdList accepts a new argument: skip_info. When set to True it ignores any 'code':'info' entry (skip_info=False by default). That allows us to fix some of the tests in t9831-git-p4-triggers.sh known to be broken with verobse p4 triggers Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2017-07-13git-p4: parse marshal output "p4 -G" in p4 changesMiguel Torroja2-29/+58 The option -G of p4 (python marshal output) gives more context about the data being output. That's useful when using the command "change -o" as we can distinguish between warning/error line and real change description. This fixes the case where a p4 trigger for "p4 change" is set and the command git-p4 submit is run. Signed-off-by: Miguel Torroja <miguel.torroja@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>