{"shas":[["d0368c73bbb2101743b02e3e8ba8c7262dd9230b","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","git-remote-testgit: exit gracefully after push\n\nThe core of the helper script is a loop reading commands.\nAfter most commands, we want to read more, until we get an\nempty command that signals we're done. The \"export\" command\nis different, though; all of the rest of the input goes to\nfast-import, and there is nothing left for us to read.  This\ncaused us to print a warning that we got EOF, even though it\nis expected in this case.\n\nThis was just a warning, so it didn't cause any tests to\nfail, but the testgit helper is supposed to act as a\nreference implementation. We should try to set a good\nexample.\n\nThis patch lets each command handler tell the main loop\nwhether it should expect more commands or not; the handler\nexits gracefully if no more are expected.","Jeff King"],["6e56be16006017adbdfa03ced39fc56134204401","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","t5800: factor out some ref tests\n\nThese are a little hard to read, and I'm about to add more\njust like them. Plus the failure output is nicer if we use\ntest_cmp than a comparison with \"test\".","Jeff King"],["583096d6393cf6119faa71e0ccf92e2d2324b7c8","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","t5800: document some non-functional parts of remote helpers\n\nThese are all things one might expect to work in a helper\nthat is capable of handling multiple branches (which our\ntestgit helper in theory should be able to do, as it is\nbacked by git). All of these bugs are specific to the\nimport/export codepaths, so they don't affect helpers like\ngit-remote-curl that use fetch/push commands.\n\nThe first and fourth tests are about fetching and pushing\nnew refs, and demonstrate bugs in the git_remote_helpers\nlibrary (so they would be most likely to impact helpers for\nother VCSs which import/export git).\n\nThe second test is about importing multiple refs; it\ndemonstrates a bug in git-remote-testgit, which is mostly\nfor exercising the test code. Therefore it probably doesn't\naffect anyone in practice.\n\nThe third test demonstrates a bug in git's side of the\nhelper code when the upstream has added new refs without us.\nThis could impact git users who use remote helpers to access\nforeign VCSs.\n\nAll of those bugs have fixes later in this series.\n\nThe fifth test is the most complex, and does not have a fix\nin this series. It tests pushing a ref via the export\nmechanism to a new name on the remote side (i.e.,\n\"git push $remote old:new\").\n\nThe problem is that we push all of the work of generating\nthe export stream onto fast-export, but we have no way of\ncommunicating to fast-export that this name mapping is\nhappening. So we tell fast-export to generate a stream with\nthe commits for \"old\", but we can't tell it to label them\nall as \"new\".\n\nThere are two possible solutions:\n\n  1. Indicate the mapping to fast-export, so that it can\n     generate the \"mapped\" names. Unfortunately, this is\n     somewhat difficult due to the way fast-import is\n     implemented. It feeds its revision parameters to the\n     regular rev-walking machinery, asking the revision code\n     to mark the \"source\" of each commit. So if fast-export\n     sees that we want commits from \"refs/heads/old\", but\n     also that we want to call commits from old as\n     \"refs/heads/new\", it can't distinguish between the\n     case of \"I want _only_ new, using the commits of old\"\n     and \"I want _both_ old and new, which happen to point\n     to the same commits\".\n\n     And it's important to distinguish those cases, because\n     in one, the remote will update master, and in the\n     other, it will not.\n\n     This isn't an insurmountable obstacle, but it's going\n     to mean either fast-export has to take on more of the\n     revision argument parsing and revwalking\n     responsibility, or the revision walker's show_source\n     code will have to learn about mapping names.\n\n  2. Indicate the mapping to the remote helper, who can then\n     apply the mapping to the results of the export. Right\n     now the export remote helper command has no arguments;\n     it simply says \"hey, I'm going to dump a fast-export\n     stream on you\". And the remote-helper looks through the\n     results of the stream to decide which refs are being\n     pushed. This could be extended instead to something\n     like:\n\n       export refs/heads/foo\n       export refs/heads/old:refs/heads/new\n       <blank line>\n\n     which would allow the remote helper to map names as\n     appropriate. This a reasonably elegant solution; the\n     downside is that it breaks compatibility with existing\n     remote helpers.","Jeff King"],["c1c877dcd6dba6315048ca26d78302345b2b8aaa","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","teach remote-testgit to import non-HEAD refs\n\nUpon receiving an \"import\" command, the testgit remote\nhelper would ignore the ref asked for by git and generate a\nfast-export stream based on HEAD. Instead, we should\nactually give git the ref it asked for.\n\nThis requires adding a new parameter to the export_repo\nmethod in the remote-helpers python library, which may be\nused by code outside of git.git. We use a default parameter\nso that callers without the new parameter will get the same\nbehavior as before.","Jeff King"],["2e1ef1ae8a5f67ca53a2d70c1eb36c4f7305e889","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","teach remote-testgit to import multiple refs\n\nWhen git wants to fetch multiple refs from a remote helper,\nit will issue multiple \"import\" lines. In this case, testgit\nwould then run multiple fast-exports, one per commit. Not\nonly is this inefficient (since the refs may have shared\nhistory), but the data stream will appear bogus to\nfast-import, which sees the output of the exports\nconcatenated (specifically, each export starts with\n\"feature\" lines, which are not allowed to come after \"data\"\nlines).\n\nInstead, the helper needs to collect the list of refs to be\nimported, and then run a single fast-import with all of the\nrefs (once git has signalled to us the list is done by\nhanging up).","Jeff King"],["a3fa477f35a3b506cf75f844d07e79f9f1a43072","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","transport-helper: don't feed bogus refs to export push\n\nWhen we want to push to a remote helper that has the\n\"export\" capability, we collect all of the refs we want to\npush and then feed them to fast-export.\n\nHowever, the list of refs is actually a list of remote refs,\nnot local refs. The mapped local refs are included via the\npeer_ref pointer. So when we add an argument to our\nfast-export command line, we must be sure to use the local\npeer_ref name (and if there is no local name, it is because\nwe are not actually sending that ref, or we may not even\nhave the ref at all).","Jeff King"],["3065da1dd8ccba5367e2b5c9fe8ca177c7a428a2","696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","git_remote_helpers: push all refs during a non-local export\n\nWhen a remote helper exports to a non-local git repo, the\nsteps are roughly:\n\n  1. fast-export into a local staging area; the set of\n     interesting refs is defined by what is in the fast-export\n     stream\n\n  2. git push from the staging area to the non-local repo\n\nIn the second step, we should explicitly push all refs, not\njust matching ones. This will let us push refs that do not\nyet exist in the remote repo.","Jeff King"]],"ref":"refs/heads/jk/remote-helpers","size":7,"head":"3065da1dd8ccba5367e2b5c9fe8ca177c7a428a2","push_id":33334487}