{"push_id":694815693,"size":152,"distinct_size":0,"ref":"refs/heads/jk/setup-bare-worktree","head":"78b6919235a9e8d05e97b586cfb789419b8a5047","before":"0bdd022e910221d9fa4421125eed054260db599e","commits":[{"sha":"e41bf352e3280e6990605a18ebbbd40c6f1c0d6d","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: drop default_remote_name variable\n\nWhen we read the remote config from disk, we update a\ndefault_remote_name variable if we see branch.*.remote\nconfig for the current branch. This isn't wrong, or even all\nthat complicated, but it is a bit simpler (because it\nreduces our overall state) to just lazily compute the\ndefault when we need it.\n\nThe ulterior motive here is that the push config uses a\nsimilar structure, and _is_ much more complicated as a\nresult. That will be simplified in a future patch, and it's\nmore readable if the logic for remotes and push-remotes\nmatches.\n\nNote that we also used default_remote_name as a signal that\nthe remote config has been loaded; after this patch, we now\nuse an explicit flag.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/e41bf352e3280e6990605a18ebbbd40c6f1c0d6d"},{"sha":"c998b381477953361c8bf180871ecd6b57ff94ea","author":{"email":"ca5433e1cdd25b4a4001c54525dea593b33edc0c@gmail.com","name":"Paul Tan"},"message":"t5520: prevent field splitting in content comparisons\n\nMany tests in t5520 used the following to test the contents of files:\n\n\ttest `cat file` = expected\n\nor\n\n\ttest $(cat file) = expected\n\nThese 2 forms, however, will be affected by field splitting and,\ndepending on the value of $IFS, may be split into multiple arguments,\nmaking the test fail in mysterious ways.\n\nReplace the above 2 forms with:\n\n\ttest \"$(cat file)\" = expected\n\nas quoting the command substitution will prevent field splitting.\n\nSigned-off-by: Paul Tan <pyokagan@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/c998b381477953361c8bf180871ecd6b57ff94ea"},{"sha":"d12f455e44bc3c90bf06b7123cebe0c82a039c63","author":{"email":"ca5433e1cdd25b4a4001c54525dea593b33edc0c@gmail.com","name":"Paul Tan"},"message":"t5520: test no merge candidates cases\n\na8c9bef (pull: improve advice for unconfigured error case, 2009-10-05)\nfully established the current advices given by git-pull for the\ndifferent cases where git-fetch will not have anything marked for merge:\n\n1. We fetched from a specific remote, and a refspec was given, but it\n   ended up not fetching anything. This is usually because the user\n   provided a wildcard refspec which had no matches on the remote end.\n\n2. We fetched from a non-default remote, but didn't specify a branch to\n   merge. We can't use the configured one because it applies to the\n   default remote, and thus the user must specify the branches to merge.\n\n3. We fetched from the branch's or repo's default remote, but:\n\n   a. We are not on a branch, so there will never be a configured branch\n      to merge with.\n\n   b. We are on a branch, but there is no configured branch to merge\n      with.\n\n4. We fetched from the branch's or repo's default remote, but the\n   configured branch to merge didn't get fetched (either it doesn't\n   exist, or wasn't part of the configured fetch refspec)\n\nImplement tests for the above 5 cases to ensure that the correct code\npaths are triggered for each of these cases.\n\nSigned-off-by: Paul Tan <pyokagan@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/d12f455e44bc3c90bf06b7123cebe0c82a039c63"},{"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":false,"url":"https://api.github.com/repos/peff/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":false,"url":"https://api.github.com/repos/peff/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":false,"url":"https://api.github.com/repos/peff/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":false,"url":"https://api.github.com/repos/peff/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":false,"url":"https://api.github.com/repos/peff/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":false,"url":"https://api.github.com/repos/peff/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":false,"url":"https://api.github.com/repos/peff/git/commits/3a429d0af342d85ef6d561e3a60ae8793a34ae78"},{"sha":"1ca41a19323d455cf0028001677f3adfae0d4cc4","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: untangle error logic in branch_get_upstream\n\nThe error-diagnosis logic in branch_get_upstream was copied\nstraight from sha1_name.c in the previous commit. However,\nbecause we check all error cases and upfront and then later\ndiagnose them, the logic is a bit tangled. In particular:\n\n  - if branch->merge[0] is NULL, we may end up dereferencing\n    it for an error message (in practice, it should never be\n    NULL, so this is probably not a triggerable bug).\n\n  - We may enter the code path because branch->merge[0]->dst\n    is NULL, but we then start our error diagnosis by\n    checking whether our local branch exists. But that is\n    only relevant to diagnosing missing merge config, not a\n    missing tracking ref; our diagnosis may hide the real\n    problem.\n\nInstead, let's just use a sequence of \"if\" blocks to check\nfor each error type, diagnose it, and return NULL.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/1ca41a19323d455cf0028001677f3adfae0d4cc4"},{"sha":"979cb245e29b35812d2d71a04069ba7a4580981f","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"remote.c: return upstream name from stat_tracking_info\n\nAfter calling stat_tracking_info, callers often want to\nprint the name of the upstream branch (in addition to the\ntracking count). To do this, they have to access\nbranch->merge->dst[0] themselves. This is not wrong, as the\nreturn value from stat_tracking_info tells us whether we\nhave an upstream branch or not. But it is a bit leaky, as we\nmake an assumption about how it calculated the upstream\nname.\n\nInstead, let's add an out-parameter that lets the caller\nknow the upstream name we found.\n\nAs a bonus, we can get rid of the unusual tri-state return\nfrom the function. We no longer need to use it to\ndifferentiate between \"no tracking config\" and \"tracking ref\ndoes not exist\" (since you can check the upstream_name for\nthat), so we can just use the usual 0/-1 convention for\nsuccess/error.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/979cb245e29b35812d2d71a04069ba7a4580981f"},{"sha":"e291c75a95d60862cbe12897b5cffb01ba4cedd5","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":false,"url":"https://api.github.com/repos/peff/git/commits/e291c75a95d60862cbe12897b5cffb01ba4cedd5"},{"sha":"a1ad0eb0cb1c9c83492b17d7a218be084466bf9a","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":false,"url":"https://api.github.com/repos/peff/git/commits/a1ad0eb0cb1c9c83492b17d7a218be084466bf9a"},{"sha":"48c58471c2d4d7293272448a18801cd27555f6b5","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":false,"url":"https://api.github.com/repos/peff/git/commits/48c58471c2d4d7293272448a18801cd27555f6b5"},{"sha":"adfe5d04345631299f9a4518d56c6dd3d47eb0b3","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":false,"url":"https://api.github.com/repos/peff/git/commits/adfe5d04345631299f9a4518d56c6dd3d47eb0b3"},{"sha":"3dbe9db01bd9c0b0701f72a631ac15b1791f6642","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":false,"url":"https://api.github.com/repos/peff/git/commits/3dbe9db01bd9c0b0701f72a631ac15b1791f6642"},{"sha":"29bc88505f22068d7ee6694240e6b13fddb5d059","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":false,"url":"https://api.github.com/repos/peff/git/commits/29bc88505f22068d7ee6694240e6b13fddb5d059"},{"sha":"9afbb2dc371441ad250d5e094277699b58dbd88c","author":{"email":"6b3799be4300e44489a08090123f3842e6419da5@diamand.org","name":"Luke Diamand"},"message":"git-p4: add failing test for P4EDITOR handling\n\nAdd test case that git-p4 handles a setting of P4EDITOR\nthat takes arguments, e.g. \"gvim -f\". This currently fails.\n\nSigned-off-by: Luke Diamand <luke@diamand.org>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/9afbb2dc371441ad250d5e094277699b58dbd88c"},{"sha":"2dade7a7b20902a145d1c130830bcb4d4b288a32","author":{"email":"6b3799be4300e44489a08090123f3842e6419da5@diamand.org","name":"Luke Diamand"},"message":"git-p4: fix handling of multi-word P4EDITOR\n\nThis teaches git-p4 to pass the P4EDITOR variable to the\nshell for expansion, so that any command-line arguments are\ncorrectly handled. Without this, git-p4 can only launch the\neditor if P4EDITOR is solely the path to the binary, without\nany arguments.\n\nThis also adjusts t9805, which relied on the previous behaviour.\n\nSuggested-by: Jonathan Nieder <jrnieder@gmail.com>\nSigned-off-by: Luke Diamand <luke@diamand.org>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/2dade7a7b20902a145d1c130830bcb4d4b288a32"}]}