{"push_id":1858699420,"size":49,"distinct_size":44,"ref":"refs/heads/pu","head":"b23e1a8db06f4faf2bd4de20b2d480e695f62621","before":"bfcf2e3c21fc2b7ed44a043b0f66382a58a62140","commits":[{"sha":"c625bf0ee80a2362ce59819ce011ee17f2a6b2ce","author":{"name":"Miguel Torroja","email":"49dfc8d6ec5b3bdc93ef3fb16f813b357260df1b@gmail.com"},"message":"git-p4: git-p4 tests with p4 triggers\n\nSome p4 triggers in the server side generate some warnings when\nexecuted. Unfortunately those messages are mixed with the output of\np4 commands. A few git-p4 commands don't expect extra messages or output\nlines and may fail with verbose triggers.\nNew tests added are known to be broken.\n\nSigned-off-by: Miguel Torroja <miguel.torroja@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/c625bf0ee80a2362ce59819ce011ee17f2a6b2ce"},{"sha":"b596b3b920208acb775bb632288976377636ccd1","author":{"name":"Miguel Torroja","email":"49dfc8d6ec5b3bdc93ef3fb16f813b357260df1b@gmail.com"},"message":"git-p4: parse marshal output \"p4 -G\" in p4 changes\n\nThe option -G of p4 (python marshal output) gives more context about the\ndata being output. That's useful when using the command \"change -o\" as\nwe can distinguish between warning/error line and real change description.\n\nThis fixes the case where a p4 trigger for  \"p4 change\" is set and the command git-p4 submit is run.\n\nSigned-off-by: Miguel Torroja <miguel.torroja@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/b596b3b920208acb775bb632288976377636ccd1"},{"sha":"1997e91f4b36649e7e4f693ca9f35c7a6219de8c","author":{"name":"Miguel Torroja","email":"49dfc8d6ec5b3bdc93ef3fb16f813b357260df1b@gmail.com"},"message":"git-p4: filter for {'code':'info'} in p4CmdList\n\nThe function p4CmdList accepts a new argument: skip_info. When set to\nTrue it ignores any 'code':'info' entry (skip_info=False by default).\n\nThat allows us to fix some of the tests in t9831-git-p4-triggers.sh\nknown to be broken with verobse p4 triggers\n\nSigned-off-by: Miguel Torroja <miguel.torroja@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/1997e91f4b36649e7e4f693ca9f35c7a6219de8c"},{"sha":"8b65a34c4a12cdaae7f43f65f760da0f48ad67e3","author":{"name":"Stefan Beller","email":"75e5af3a5fc6e432c184f339c5c73c118a246be6@google.com"},"message":"commit: convert lookup_commit_graft to struct object_id\n\nWith this patch, commit.h doesn't contain the string 'sha1' any more.\n\nSigned-off-by: Stefan Beller <sbeller@google.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/8b65a34c4a12cdaae7f43f65f760da0f48ad67e3"},{"sha":"84571760ca96d244e4fff06819fab119947d792e","author":{"name":"Stefan Beller","email":"75e5af3a5fc6e432c184f339c5c73c118a246be6@google.com"},"message":"tag: convert gpg_verify_tag to use struct object_id\n\nSigned-off-by: Stefan Beller <sbeller@google.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/84571760ca96d244e4fff06819fab119947d792e"},{"sha":"2eda0102beb85b97bd43708176d81feabaf161e8","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"check return value of verify_ref_format()\n\nUsers of the ref-filter code must call verify_ref_format()\nbefore formatting any refs, but most ignore its return\nvalue. This means we may print an error on a syntactically\nbogus pattern, but keep going anyway.\n\nIn most cases this results in a fatal error when we actually\ntry to format a ref. But if you have no refs to show at all,\nthen the behavior is confusing: git prints the error from\nverify_ref_format(), then exits with code 0 without showing\nany output.  Let's instead abort immediately if we know we\nhave a bogus format.\n\nWe'll output the usage information if we have it handy (just\nlike the existing call in cmd_for_each_ref() does), and\notherwise just die().\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/2eda0102beb85b97bd43708176d81feabaf161e8"},{"sha":"5d3d0681abb8f2bc2383ee7660cf2b02e89cdd07","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"docs/for-each-ref: update pointer to color syntax\n\nThe documentation for the %(color) placeholder refers to the\ncolor.branch.* config for more details. But those details\nmoved to their own section in b92c1a28f\n(Documentation/config.txt: describe 'color' value type in\nthe \"Values\" section, 2015-03-03).  Let's update our\npointer. We can steal the text from 30cfe72d3 (pretty: fix\ndocument link for color specification, 2016-10-11), which\nfixed the same problem in a different place.\n\nWhile we're at it, let's give an example, which makes the\nsyntax much more clear than just the text.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/5d3d0681abb8f2bc2383ee7660cf2b02e89cdd07"},{"sha":"097b681baac3a5e9455c74e3072a458249691e40","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"t: use test_decode_color rather than literal ANSI codes\n\nWhen we put literal ANSI terminal codes into our test\nscripts, it makes diffs on those scripts hard to read (the\ncolors may be indistinguishable from diff coloring, or in\nthe case of a reset, may not be visible at all).\n\nSome scripts get around this by including human-readable\nnames and converting to literal codes with a git-config\nhack. This makes the actual code diffs look OK, but test_cmp\noutput suffers from the same problem.\n\nLet's use test_decode_color instead, which turns the codes\ninto obvious text tags.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/097b681baac3a5e9455c74e3072a458249691e40"},{"sha":"51331aad69a1d89a8b6d1ff82bb5fedbdb6ccc6a","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: simplify automatic color reset\n\nWhen the user-format doesn't add the closing color reset, we\nadd one automatically. But we do so by parsing the \"reset\"\nstring. We can just use the baked-in string literal, which\nis simpler.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/51331aad69a1d89a8b6d1ff82bb5fedbdb6ccc6a"},{"sha":"4a68e36d7d106abaf44e3ac960276145b5a25723","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: abstract ref format into its own struct\n\nThe ref-filter module provides routines for formatting a ref\nfor output. The fundamental interface for the format is a\n\"const char *\" containing the format, and any additional\noptions need to be passed to each invocation of\nshow_ref_array_item.\n\nInstead, let's make a ref_format struct that holds the\nformat, along with any associated format options. That will\nmake some enhancements easier in the future:\n\n  1. new formatting options can be added without disrupting\n     existing callers\n\n  2. some state can be carried in the struct rather than as\n     global variables\n\nFor now this just has the text format itself along with the\nquote_style option, but we'll add more fields in future patches.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/4a68e36d7d106abaf44e3ac960276145b5a25723"},{"sha":"bf285ae6dbfa8e2b847940e6ad987ff3cbe40712","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: move need_color_reset_at_eol into ref_format\n\nCalling verify_ref_format() doesn't just confirm that the\nformat is sane; it actually sets some global variables that\nwill be used later when formatting the refs. These logically\nshould belong to the ref_format, which would make it\npossible to use multiple formats within a single program\ninvocation.\n\nLet's move one such flag into the ref_format struct. There\nare still others that would need to be moved before it would\nbe safe to use multiple formats, but this commit gives a\nblueprint for how that should look.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/bf285ae6dbfa8e2b847940e6ad987ff3cbe40712"},{"sha":"18a2565016d45538345a06cd9b912040b5581fc1","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: provide a function for parsing sort options\n\nThe ref-filter module currently provides a callback suitable\nfor parsing command-line --sort options. But since git-tag\nalso supports the tag.sort config option, it needs a\nfunction whose implementation is quite similar, but with a\nslightly different interface. The end result is that\nbuiltin/tag.c has a copy-paste of parse_opt_ref_sorting().\n\nInstead, let's provide a function to parse an arbitrary\nsort string, which we can then trivially wrap to make the\nparse_opt variant.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/18a2565016d45538345a06cd9b912040b5581fc1"},{"sha":"aa8a5d144da4e4ec43580831ff4a741538d21db4","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: make parse_ref_filter_atom a private function\n\nThe parse_ref_filter_atom() function really shouldn't be\nexposed outside of ref-filter.c; its return value is an\ninteger index into an array that is private in that file.\n\nSince the previous commit removed the sole external caller\n(and replaced it with a public function at a more\nappropriately level), we can just make this static.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/aa8a5d144da4e4ec43580831ff4a741538d21db4"},{"sha":"29ef53cd361e8751f9f2f40811af0ce863e449b6","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: factor out the parsing of sorting atoms\n\nWe parse sort strings as single formatting atoms, and just\nbuild on parse_ref_filter_atom(). Let's pull this idea into\nits own function, since it's about to get a little more\ncomplex. As a bonus, we can give the function a slightly\nmore natural interface, since our single atoms are in their\nown strings.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/29ef53cd361e8751f9f2f40811af0ce863e449b6"},{"sha":"ab7ded34d6a9a5d4c8bf073cb9627b8054f430cf","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: pass ref_format struct to atom parsers\n\nThe callback for parsing each formatting atom gets to see\nonly the atom struct (which it's filling in) and the text to\nbe parsed. This doesn't leave any room for it to behave\ndifferently based on context known only to the ref_format.\n\nWe can solve this by passing in the surrounding ref_format\nto each parser. Note that this makes things slightly awkward\nfor sort strings, which parse atoms without having a\nref_format. We'll solve that by using a dummy ref_format\nwith default parameters.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/ab7ded34d6a9a5d4c8bf073cb9627b8054f430cf"},{"sha":"136c8c8b8fa39f1315713248473dececf20f8fe7","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"color: check color.ui in git_default_config()\n\nBack in prehistoric times, our decision on whether or not to\nshow color by default relied on using a config callback that\neither did or didn't load color config like color.diff.\nWhen we introduced color.ui, we put it in the same boat:\ncommands had to manually respect it by using git_color_config()\nor its git_color_default_config() convenience wrapper.\n\nBut in 4c7f1819b (make color.ui default to 'auto',\n2013-06-10), that changed. Since then, we default color.ui\nto auto in all programs, meaning that even plumbing commands\nlike \"git diff-tree --pretty\" might colorize the output.\nNobody seems to have complained in the intervening years,\npresumably because the \"is stdout a tty\" check does a good\njob of catching the right cases.\n\nBut that leaves an interesting curiosity: color.ui defaults\nto auto even in plumbing, but you can't actually _disable_\nthe color via config. So if you really hate color and set\n\"color.ui\" to false, diff-tree will still show color (but\nporcelain like git-diff won't).  Nobody noticed that either,\nprobably because very few people disable color.\n\nOne could argue that the plumbing should _always_ disable\ncolor unless an explicit --color option is given on the\ncommand line. But in practice, this creates a lot of\ncomplications for scripts which do want plumbing to show\nuser-visible output. They can't just pass \"--color\" blindly;\nthey need to check the user's config and decide what to\nsend.\n\nGiven that nobody has complained about the current behavior,\nlet's assume it's a good path, and follow it to its\nconclusion: supporting color.ui everywhere.\n\nNote that you can create havoc by setting color.ui=always in\nyour config, but that's more or less already the case. We\ncould disallow it entirely, but it is handy for one-offs\nlike:\n\n  git -c color.ui=always foo >not-a-tty\n\nwhen \"foo\" does not take a --color option itself.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/136c8c8b8fa39f1315713248473dececf20f8fe7"},{"sha":"d8b68686a4cc8a486823dd356ed4dba0e51536ea","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"for-each-ref: load config earlier\n\nIn most commands we load config before parsing command line\noptions, since it lets the latter override the former with a\nsimple variable assignment. In the case of for-each-ref,\nthough, we do it in the reverse order. This is OK with\nthe current code, since there's no interaction between the\nconfig and command-line options.\n\nHowever, as the ref-filter code starts to care about config\nduring verify_ref_format(), we'll want to make sure the\nconfig is loaded. Let's bump the config to the usual spot\nnear the top of the function.\n\nWe can drop the comment there; it's impossible to keep a\n\"why we load the config\" comment like this up to date with\nevery config option we might be interested in. And indeed,\nit's already stale; we'd care about core.abbrev, for\ninstance, when %(objectname:short) is used.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/d8b68686a4cc8a486823dd356ed4dba0e51536ea"},{"sha":"d75dfb1089d471501f6042341bed647525f6e293","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"rev-list: pass diffopt->use_colors through to pretty-print\n\nWhen rev-list pretty-prints a commit, it creates a new\npretty_print_context and copies items from the rev_info\nstruct. We don't currently copy the \"use_color\" field,\nthough. Nobody seems to have noticed because the only part\nof pretty.c that cares is the %C(auto,...) placeholder, and\npresumably not many people use that with the rev-list\nplumbing (as opposed to with git-log).\n\nIt will become more noticeable in a future patch, though,\nwhen we start treating all user-format colors as auto-colors\n(in which case it would become impossible to format colors\nwith rev-list, even with --color=always).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/d75dfb1089d471501f6042341bed647525f6e293"},{"sha":"18fb7ffc3dc9df081c241d6b7105b4058d5746d3","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"pretty: respect color settings for %C placeholders\n\nThe color placeholders have traditionally been\nunconditional, showing colors even when git is not otherwise\nconfigured to do so. This was not so bad for their original\nuse, which was on the command-line (and the user could\ndecide at that moment whether to add colors or not). But\nthese days we have configured formats via pretty.*, and\nthose should operate correctly in multiple contexts.\n\nIn 3082517 (log --format: teach %C(auto,black) to respect\ncolor config, 2012-12-17), we gave an extended placeholder\nthat could be used to accomplish this. But it's rather\nclunky to use, because you have to specify it individually\nfor each color (and their matching resets) in the format.\nWe shied away from just switching the default to auto,\nbecause it is technically breaking backwards compatibility.\n\nHowever, there's not really a use case for unconditional\ncolors. The most plausible reason you would want them is to\nredirect \"git log\" output to a file. But there, the right\nanswer is --color=always, as it does the right thing both\nwith custom user-format colors and git-generated colors.\n\nSo let's switch to the more useful default. In the\noff-chance that somebody really does find a use for\nunconditional colors without wanting to enable the rest of\ngit's colors, we provide a new %C(always,...) to enable the\nold behavior. And we can remind them of --color=always in\nthe documentation.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/18fb7ffc3dc9df081c241d6b7105b4058d5746d3"},{"sha":"11b087adfd469ca597f1d269314f8cad32d0d72f","author":{"name":"Jeff King","email":"7e57302763bea699aee296fb53304dc616ab92d5@peff.net"},"message":"ref-filter: consult want_color() before emitting colors\n\nWhen color placeholders like %(color:red) are used in a\nref-filter format, we unconditionally output the colors,\neven if the user has asked us for no colors. This usually\nisn't a problem when the user is constructing a --format on\nthe command line, but it means we may do the wrong thing\nwhen the format is fed from a script or alias. For example:\n\n   $ git config alias.b 'branch --format=%(color:green)%(refname)'\n   $ git b --no-color\n\nshould probably omit the green color. Likewise, running:\n\n   $ git b >branches\n\nshould probably also omit the color, just as we would for\nall baked-in coloring (and as we recently started to do for\nuser-specified colors in --pretty formats).\n\nThis commit makes both of those cases work by teaching\nthe ref-filter code to consult want_color() before\noutputting any color. The color flag in ref_format defaults\nto \"-1\", which means we'll consult color.ui, which in turn\ndefaults to the usual isatty() check on stdout. However,\ncallers like git-branch which support their own color config\n(and command-line options) can override that.\n\nThe new tests independently cover all three of the callers\nof ref-filter (for-each-ref, tag, and branch). Even though\nthese seem redundant, it confirms that we've correctly\nplumbed through all of the necessary config to make colors\nwork by default.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/git/git/commits/11b087adfd469ca597f1d269314f8cad32d0d72f"}]}
{"actor":{"display_login":"gitster"}}