{"push_id":672467932,"size":52,"distinct_size":52,"ref":"refs/heads/pu","head":"e7e06d532166df7a296b8750c147a92711b07f85","before":"1d773433223f4970db308572783007b317efa197","commits":[{"sha":"92de92172d1c01f3029d592f7e0f15d52149200b","author":{"email":"d4d2cc2a6ec7b2aa587d4887cc5ed200f9b685a1@imag.fr","name":"Matthieu Moy"},"message":"Documentation/log: clarify sha1 non-abbreviation in log --raw\n\nSigned-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/92de92172d1c01f3029d592f7e0f15d52149200b"},{"sha":"ee2499fe38d93fcbf4cbecdf83b32a495b0b12b9","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: refactor setup of branch->merge list\n\nWhen we call branch_get() to lookup or create a \"struct\nbranch\", we make sure the \"merge\" field is filled in so that\ncallers can access it. But the conditions under which we do\nso are a little confusing, and can lead to two funny\nsituations:\n\n  1. If there's no branch.*.remote config, we cannot provide\n     branch->merge (because it is really just an application\n     of branch.*.merge to our remote's refspecs). But\n     branch->merge_nr may be non-zero, leading callers to be\n     believe they can access branch->merge (e.g., in\n     branch_merge_matches and elsewhere).\n\n     It doesn't look like this can cause a segfault in\n     practice, as most code paths dealing with merge config\n     will bail early if there is no remote defined. But it's\n     a bit of a dangerous construct.\n\n     We can fix this by setting merge_nr to \"0\" explicitly\n     when we realize that we have no merge config. Note that\n     merge_nr also counts the \"merge_name\" fields (which we\n     _do_ have; that's how merge_nr got incremented), so we\n     will \"lose\" access to them, in the sense that we forget\n     how many we had. But no callers actually care; we use\n     merge_name only while iteratively reading the config,\n     and then convert it to the final \"merge\" form the first\n     time somebody calls branch_get().\n\n  2. We set up the \"merge\" field every time branch_get is\n     called, even if it has already been done. This leaks\n     memory.\n\n     It's not a big deal in practice, since most code paths\n     will access only one branch, or perhaps each branch\n     only one time. But if you want to be pathological, you\n     can leak arbitrary memory with:\n\n       yes @{upstream} | head -1000 | git rev-list --stdin\n\n     We can fix this by skipping setup when branch->merge is\n     already non-NULL.\n\nIn addition to those two fixes, this patch pushes the \"do we\nneed to setup merge?\" logic down into set_merge, where it is\na bit easier to follow.\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/sunny256/git/commits/ee2499fe38d93fcbf4cbecdf83b32a495b0b12b9"},{"sha":"9e3751d4437b43e72497178774c74be1ceac28b9","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: drop \"remote\" pointer from \"struct branch\"\n\nWhen we create each branch struct, we fill in the\n\"remote_name\" field from the config, and then fill in the\nactual \"remote\" field (with a \"struct remote\") based on that\nname. However, it turns out that nobody really cares about\nthe latter field. The only two sites that access it at all\nare:\n\n  1. git-merge, which uses it to notice when the branch does\n     not have a remote defined. But we can easily replace this\n     with looking at remote_name instead.\n\n  2. remote.c itself, when setting up the @{upstream} merge\n     config. But we don't need to save the \"remote\" in the\n     \"struct branch\" for that; we can just look it up for\n     the duration of the operation.\n\nSo there is no need to have both fields; they are redundant\nwith each other (the struct remote contains the name, or you\ncan look up the struct from the name). It would be nice to\nsimplify this, especially as we are going to add matching\npushremote config in a future patch (and it would be nice to\nkeep them consistent).\n\nSo which one do we keep and which one do we get rid of?\n\nIf we had a lot of callers accessing the struct, it would be\nmore efficient to keep it (since you have to do a lookup to\ngo from the name to the struct, but not vice versa). But we\ndon't have a lot of callers; we have exactly one, so\nefficiency doesn't matter. We can decide this based on\nsimplicity and readability.\n\nAnd the meaning of the struct value is somewhat unclear. Is\nit always the remote matching remote_name? If remote_name is\nNULL (i.e., no per-branch config), does the struct fall back\nto the \"origin\" remote, or is it also NULL? These questions\nwill get even more tricky with pushremotes, whose fallback\nbehavior is more complicated. So let's just store the name,\nwhich pretty clearly represents the branch.*.remote config.\nAny lookup or fallback behavior can then be implemented in\nhelper functions.\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/sunny256/git/commits/9e3751d4437b43e72497178774c74be1ceac28b9"},{"sha":"f052154db332e48ea35b1a0d783361a40a361250","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: hoist branch.*.remote lookup out of remote_get_1\n\nWe'll want to use this logic as a fallback when looking up\nthe pushremote, so let's pull it out into its own function.\n\nWe don't technically need to make this available outside of\nremote.c, but doing so will provide a consistent API with\npushremote_for_branch, which we will add later.\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/sunny256/git/commits/f052154db332e48ea35b1a0d783361a40a361250"},{"sha":"da66b2743cf7244e52c4b9d91646b782cd4f7eeb","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: provide per-branch pushremote name\n\nWhen remote.c loads its config, it records the\nbranch.*.pushremote for the current branch along with the\nglobal remote.pushDefault value, and then binds them into a\nsingle value: the default push for the current branch. We\nthen pass this value (which may be NULL) to remote_get_1\nwhen looking up a remote for push.\n\nThis has a few downsides:\n\n  1. It's confusing. The early-binding of the \"current\n     value\" led to bugs like the one fixed by 98b406f\n     (remote: handle pushremote config in any order,\n     2014-02-24). And the fact that pushremotes fall back to\n     ordinary remotes is not explicit at all; it happens\n     because remote_get_1 cannot tell the difference between\n     \"we are not asking for the push remote\" and \"there is\n     no push remote configured\".\n\n  2. It throws away intermediate data. After read_config()\n     finishes, we have no idea what the value of\n     remote.pushDefault was, because the string has been\n     overwritten by the current branch's\n     branch.*.pushremote.\n\n  3. It doesn't record other data. We don't note the\n     branch.*.pushremote value for anything but the current\n     branch.\n\nLet's make this more like the fetch-remote config. We'll\nrecord the pushremote for each branch, and then explicitly\ncompute the correct remote for the current branch at the\ntime of reading.\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/sunny256/git/commits/da66b2743cf7244e52c4b9d91646b782cd4f7eeb"},{"sha":"8770e6fbb28dffdf9e00d05365120e438d3d236f","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: hoist read_config into remote_get_1\n\nBefore the previous commit, we had to make sure that\nread_config() was called before entering remote_get_1,\nbecause we needed to pass pushremote_name by value. But now\nthat we pass a function, we can let remote_get_1 handle\nloading the config itself, turning our wrappers into true\none-liners.\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/sunny256/git/commits/8770e6fbb28dffdf9e00d05365120e438d3d236f"},{"sha":"a9f9f8cc1f59104257eb1a11a2d048f54dd92ee6","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: introduce branch_get_upstream helper\n\nAll of the information needed to find the @{upstream} of a\nbranch is included in the branch struct, but callers have to\nnavigate a series of possible-NULL values to get there.\nLet's wrap that logic up in an easy-to-read helper.\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/sunny256/git/commits/a9f9f8cc1f59104257eb1a11a2d048f54dd92ee6"},{"sha":"3a429d0af342d85ef6d561e3a60ae8793a34ae78","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: report specific errors from branch_get_upstream\n\nWhen the previous commit introduced the branch_get_upstream\nhelper, there was one call-site that could not be converted:\nthe one in sha1_name.c, which gives detailed error messages\nfor each possible failure.\n\nLet's teach the helper to optionally report these specific\nerrors. This lets us convert another callsite, and means we\ncan use the helper in other locations that want to give the\nsame error messages.\n\nThe logic and error messages come straight from sha1_name.c,\nwith the exception that we start each error with a lowercase\nletter, as is our usual style (note that a few tests need\nupdated as a result).\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/sunny256/git/commits/3a429d0af342d85ef6d561e3a60ae8793a34ae78"},{"sha":"5109568fb6e0f238949ee67f9a67f9780b7754ad","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: add branch_get_push\n\nIn a triangular workflow, the place you pull from and the\nplace you push to may be different. As we have\nbranch_get_upstream for the former, this patch adds\nbranch_get_push for the latter (and as the former implements\n@{upstream}, so will this implement @{push} in a future\npatch).\n\nNote that the memory-handling for the return value bears\nsome explanation. Some code paths require allocating a new\nstring, and some let us return an existing string. We should\nprovide a consistent interface to the caller, so it knows\nwhether to free the result or not.\n\nWe could do so by xstrdup-ing any existing strings, and\nhaving the caller always free. But that makes us\ninconsistent with branch_get_upstream, so we would prefer to\nsimply take ownership of the resulting string. We do so by\nstoring it inside the \"struct branch\", just as we do with\nthe upstream refname (in that case we compute it when the\nbranch is created, but there's no reason not to just fill\nit in lazily in this case).\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/sunny256/git/commits/5109568fb6e0f238949ee67f9a67f9780b7754ad"},{"sha":"a0a76999b1936c561f9b96c131c291d425272e7c","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"sha1_name: refactor upstream_mark\n\nWe will be adding new mark types in the future, so separate\nthe suffix data from the logic.\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/sunny256/git/commits/a0a76999b1936c561f9b96c131c291d425272e7c"},{"sha":"643bcf5a5cb0e5e29674ba20cc0e0acf1e68cd81","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"sha1_name: refactor interpret_upstream_mark\n\nNow that most of the logic for our local get_upstream_branch\nhas been pushed into the generic branch_get_upstream, we can\nfold the remainder into interpret_upstream_mark.\n\nFurthermore, what remains is generic to any branch-related\n\"@{foo}\" we might add in the future, and there's enough\nboilerplate that we'd like to reuse it. Let's parameterize\nthe two operations (parsing the mark and computing its\nvalue) so that we can reuse this for \"@{push}\" in the near\nfuture.\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/sunny256/git/commits/643bcf5a5cb0e5e29674ba20cc0e0acf1e68cd81"},{"sha":"0c816a54bfed848b206ac1fb719569001d7a34ca","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"sha1_name: implement @{push} shorthand\n\nIn a triangular workflow, each branch may have two distinct\npoints of interest: the @{upstream} that you normally pull\nfrom, and the destination that you normally push to. There\nisn't a shorthand for the latter, but it's useful to have.\n\nFor instance, you may want to know which commits you haven't\npushed yet:\n\n  git log @{push}..\n\nOr as a more complicated example, imagine that you normally\npull changes from origin/master (which you set as your\n@{upstream}), and push changes to your own personal fork\n(e.g., as myfork/topic). You may push to your fork from\nmultiple machines, requiring you to integrate the changes\nfrom the push destination, rather than upstream. With this\npatch, you can just do:\n\n  git rebase @{push}\n\nrather than typing out the full name.\n\nThe heavy lifting is all done by branch_get_push; here we\njust wire it up to the \"@{push}\" syntax.\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/sunny256/git/commits/0c816a54bfed848b206ac1fb719569001d7a34ca"},{"sha":"b2b00b522edabc2377bcbdee797945e99c1566a4","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"for-each-ref: use skip_prefix instead of starts_with\n\nThis saves us having to maintain a magic number to skip past\nthe matched prefix.\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/sunny256/git/commits/b2b00b522edabc2377bcbdee797945e99c1566a4"},{"sha":"52bc818aae328c6184916ce8ece2d81a71415d34","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"for-each-ref: accept \"%(push)\" format\n\nJust as we have \"%(upstream)\" to report the \"@{upstream}\"\nfor each ref, this patch adds \"%(push)\" to match \"@{push}\".\nIt supports the same tracking format modifiers as upstream\n(because you may want to know, for example, which branches\nhave commits to push).\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/sunny256/git/commits/52bc818aae328c6184916ce8ece2d81a71415d34"},{"sha":"11c6659d85d72273a4161c8779123147b52fbcb2","author":{"email":"8d6e34f987851aa599257d3831a1af040886842f@sunshineco.com","name":"Eric Sunshine"},"message":"command-list: prepare machinery for upcoming \"common groups\" section\n\nThe ultimate goal is for \"git help\" to classify common commands by\ngroup. Toward this end, a subsequent patch will add a new \"common\ngroups\" section to command-list.txt preceding the actual command list.\nAs preparation, teach existing command-list.txt parsing machinery, which\ndoesn't care about grouping, to skip over this upcoming \"common groups\"\nsection.\n\nSigned-off-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>\nReviewed-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/11c6659d85d72273a4161c8779123147b52fbcb2"},{"sha":"413f50b901f5f5addd7404516cdd3e8ee8a4ac25","author":{"email":"b028b2e9b6f5ed2594fb0bccfcf9bf86df8374b8@gmail.com","name":"Sébastien Guimmara"},"message":"command-list.txt: add the common groups block\n\nThe ultimate goal is for \"git help\" to display common commands in\ngroups rather than alphabetically. As a first step, define the\ngroups in a new block, and then assign a group to each\ncommon command.\n\nAdd a block at the beginning of command-list.txt:\n\n    init         start a working area (see also: git help tutorial)\n    worktree     work on the current change (see also:[...]\n    info         examine the history and state (see also: git [...]\n    history      grow, mark and tweak your history\n    remote       collaborate (see also: git help workflows)\n\nstoring information about common commands group, then map each common\ncommand to a group:\n\n    git-add          mainporcelain        common worktree\n\nHelped-by: Eric Sunshine <sunshine@sunshineco.com>\nHelped-by: Junio C Hamano <gitster@pobox.com>\nHelped-by:  Emma Jane Hogbin Westby <emma.westby@gmail.com>\nSigned-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>\nReviewed-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/413f50b901f5f5addd7404516cdd3e8ee8a4ac25"},{"sha":"527ec3980bcf9868e2b726664f13532ac73d3c3f","author":{"email":"8d6e34f987851aa599257d3831a1af040886842f@sunshineco.com","name":"Eric Sunshine"},"message":"generate-cmdlist: parse common group commands\n\nParse the group block to create the array of group descriptions:\n\nstatic char *common_cmd_groups[] = {\n    N_(\"starting a working area\"),\n    N_(\"working on the current change\"),\n    N_(\"working with others\"),\n    N_(\"examining the history and state\"),\n    N_(\"growing, marking and tweaking your history\"),\n};\n\nthen map each element of common_cmds[] to a group via its index:\n\nstatic struct cmdname_help common_cmds[] = {\n    {\"add\", N_(\"Add file contents to the index\"), 1},\n    {\"branch\", N_(\"List, create, or delete branches\"), 4},\n    {\"checkout\", N_(\"Checkout a branch or paths to the ...\"), 4},\n    {\"clone\", N_(\"Clone a repository into a new directory\"), 0},\n    {\"commit\", N_(\"Record changes to the repository\"), 4},\n    ...\n};\n\nso that 'git help' can print those commands grouped by theme.\n\nOnly commands tagged with an attribute from the group block are emitted to\ncommon_cmds[].\n\n[commit message by Sébastien Guimmara <sebastien.guimmara@gmail.com>]\n\nSigned-off-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>\nReviewed-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/527ec3980bcf9868e2b726664f13532ac73d3c3f"},{"sha":"2f5b4950b98bf519f67c8692a008d858f108aba9","author":{"email":"b028b2e9b6f5ed2594fb0bccfcf9bf86df8374b8@gmail.com","name":"Sébastien Guimmara"},"message":"command-list.txt: drop the \"common\" tag\n\ncommand-list.sh, retired in the previous patch, was the only\nconsumer of the \"common\" tag, so drop this now-unnecessary\nattribute.\n\nbefore:\n    git-add          mainporcelain        common worktree\n\nafter:\n    git-add          mainporcelain        worktree\n\nHelped-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>\nReviewed-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/2f5b4950b98bf519f67c8692a008d858f108aba9"},{"sha":"224147704a3696d396dae005c280f7a25de407c7","author":{"email":"b028b2e9b6f5ed2594fb0bccfcf9bf86df8374b8@gmail.com","name":"Sébastien Guimmara"},"message":"help: respect new common command grouping\n\n'git help' shows common commands in alphabetical order:\n\nThe most commonly used git commands are:\n   add        Add file contents to the index\n   bisect     Find by binary search the change that introduced a bug\n   branch     List, create, or delete branches\n   checkout   Checkout a branch or paths to the working tree\n   clone      Clone a repository into a new directory\n   commit     Record changes to the repository\n   [...]\n\nwithout any indication of how commands relate to high-level\nconcepts or each other. Revise the output to explain their relationship\nwith the typical Git workflow:\n\n  These are common Git commands used in various situations:\n\n  start a working area (see also: git help tutorial)\n     clone      Clone a repository into a new directory\n     init       Create an empty Git repository or reinitialize [...]\n\n  work on the current change (see also: git help everyday)\n     add        Add file contents to the index\n     reset      Reset current HEAD to the specified state\n\n  examine the history and state (see also: git help revisions)\n     log        Show commit logs\n     status     Show the working tree status\n\n     [...]\n\nHelped-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>\nSigned-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com>\nReviewed-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/224147704a3696d396dae005c280f7a25de407c7"},{"sha":"50581f490694c38a4b5519aa187550cf6205a490","author":{"email":"cb3fdeda273b7e4333de243ac29ae4fdc09f64ff@gmail.com","name":"Allen Hubbe"},"message":"git-send-email.perl: Add sendmail aliases support\n\nSupport sendmail (and postfix) style email aliases in git-send-email.\nThis is the format of /etc/mail/aliases, documented by `man 5 aliases`.\nThe man page may be provided by sendmail or postfix on your system, or\nby another email service that uses the same configuration file.\n\nSee also: http://www.postfix.org/aliases.5.html.\n\nThis format is more simple than the other alias file formats, so it may\nbe preferred by some users.  The format is as follows.\n\n<alias>: <address|alias>[, <address|alias>...]\n\nExample (no indent in aliases file):\n\talice: Alice W Land <awol@example.com>\n\tbob: Robert Bobbyton <bob@example.com>\n\tchloe: chloe@example.com\n\tabgroup: alice, bob\n\tbcgrp: bob, chloe, Other <o@example.com>\n\nThis patch DOES NOT support line continuations as are described by the\nspecification.  Line continuations are indicated by either (or both) a\ntrailing '\\' on the line to be continued, or leading whitespace on the\ncontinuing line.  This patch does not do anything with the trailing '\\',\nand ignores lines starting with whitespace.\n\nThis patch also ignores lines that starts with '#', comment character,\nand empty lines.\n\nSigned-off-by: Allen Hubbe <allenbh@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":true,"url":"https://api.github.com/repos/sunny256/git/commits/50581f490694c38a4b5519aa187550cf6205a490"}]}