kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Johannes Schindelin	6dca5dbf93	tests: reference `seen` wherever `pu` was referenced As our test suite partially reflects how we work in the Git project, it is natural that the branch name `pu` was used in a couple places. Since that branch was renamed to `seen`, let's use the new name consistently. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jiang Xin	7dcbeaa0df	send-pack: fix inconsistent porcelain output The porcelain output of a failed `git-push` command is inconsistent for different protocols. For example, the following `git-push` command may fail due to the failure of the `pre-receive` hook. git push --porcelain origin HEAD:refs/heads/master For SSH protocol, the porcelain output does not end with a "Done" message: To <URL/of/upstream.git> ! HEAD:refs/heads/master [remote rejected] (pre-receive hook declined) While for HTTP protocol, the porcelain output does end with a "Done" message: To <URL/of/upstream.git> ! HEAD:refs/heads/master [remote rejected] (pre-receive hook declined) Done The following code at the end of function `send_pack()` indicates that `send_pack()` should not return an error if some references are rejected in porcelain mode. int send_pack(...) ... ... if (args->porcelain) return 0; for (ref = remote_refs; ref; ref = ref->next) { switch (ref->status) { case REF_STATUS_NONE: case REF_STATUS_UPTODATE: case REF_STATUS_OK: break; default: return -1; } } return 0; } So if atomic push failed, must check the porcelain mode before return an error. And `receive_status()` should not return an error for a failed updated reference, because `send_pack()` will check them instead. Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Hariom Verma	4ef346482d	receive.denyCurrentBranch: respect all worktrees The receive.denyCurrentBranch config option controls what happens if you push to a branch that is checked out into a non-bare repository. By default, it rejects it. It can be disabled via `ignore` or `warn`. Another yet trickier option is `updateInstead`. However, this setting was forgotten when the git worktree command was introduced: only the main worktree's current branch is respected. With this change, all worktrees are respected. That change also leads to revealing another bug, i.e. `receive.denyCurrentBranch = true` was ignored when pushing into a non-bare repository's unborn current branch using ref namespaces. As `is_ref_checked_out()` returns 0 which means `receive-pack` does not get into conditional statement to switch `deny_current_branch` accordingly (ignore, warn, refuse, unconfigured, updateInstead). receive.denyCurrentBranch uses the function `refs_resolve_ref_unsafe()` (called via `resolve_refdup()`) to resolve the symbolic ref HEAD, but that function fails when HEAD does not point at a valid commit. As we replace the call to `refs_resolve_ref_unsafe()` with `find_shared_symref()`, which has no problem finding the worktree for a given branch even if it is unborn yet, this bug is fixed at the same time: receive.denyCurrentBranch now also handles worktrees with unborn branches as intended even while using ref namespaces. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jonathan Nieder	8a1b0978ab	test: request GIT_TEST_PROTOCOL_VERSION=0 when appropriate Since `8cbeba0632` (tests: define GIT_TEST_PROTOCOL_VERSION, 2019-02-25), it has been possible to run tests with a newer protocol version by setting the GIT_TEST_PROTOCOL_VERSION envvar to a version number. Tests that assume protocol v0 handle this by explicitly setting GIT_TEST_PROTOCOL_VERSION= or similar constructs like 'test -z "$GIT_TEST_PROTOCOL_VERSION" \|\| return 0' to declare that they only handle the default (v0) protocol. The emphasis there is a bit off: it would be clearer to specify GIT_TEST_PROTOCOL_VERSION=0 to inform the reader that these tests are specifically testing and relying on details of protocol v0. Do so. This way, a reader does not need to know what the default protocol version is, and the tests can continue to work when the default protocol version used by Git advances past v0. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	34066f0661	fetch: do not consider peeled tags as advertised tips Our filter_refs() function accidentally considers the target of a peeled tag to be advertised by the server, even though upload-pack on the server side does not consider it so. This can result in the client making a bogus fetch to the server, which will end with the server complaining "not our ref". Whereas the correct behavior is for the client to notice that the server will not allow the request and error out immediately. So as bugs go, this is not very serious (the outcome is the same either way -- the fetch fails). But it's worth making the logic here correct and consistent with other related cases (e.g., fetching an oid that the server did not mention at all). The crux of the issue comes from `fdb69d33c4` (fetch-pack: always allow fetching of literal SHA1s, 2017-05-15). After that, the strategy of filter_refs() is basically: - for each advertised ref, try to match it with a "sought" ref provided by the user. Skip any malformed refs (which includes peeled values like "refs/tags/foo^{}"), and place any unmatched items onto the unmatched list. - if there are unmatched sought refs, then put all of the advertised tips into an oidset, including the unmatched ones. - for each sought ref, see if it's in the oidset, in which case it's legal for us to ask the server for it The problem is in the second step. Our list of unmatched refs includes the peeled refs, even though upload-pack does not allow them to be directly fetched. So the simplest fix would be to exclude them during that step. However, we can observe that the unmatched list isn't used for anything else, and is freed at the end. We can just free those malformed refs immediately. That saves us having to check each ref a second time to see if it's malformed. Note that this code only kicks in when "strict" is in effect. I.e., if we are using the v0 protocol and uploadpack.allowReachableSHA1InWant is not in effect. With v2, all oids are allowed, and we do not bother creating or consulting the oidset at all. To future-proof our test against the upcoming GIT_TEST_PROTOCOL_VERSION flag, we'll manually mark it as a v0-only test. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	533ddba47e	pkt-line: prepare buffer before handling ERR packets Since `2d103c31c2` (pack-protocol.txt: accept error packets in any context, 2018-12-29), the pktline code will detect an ERR packet and die automatically, saving the caller from dealing with it. But we do so too early in the function, before we have terminated the buffer with a NUL. As a result, passing the ERR message to die() may result in us printing random cruft from a previous packet. This doesn't trigger memory tools like ASan because we reuse the same buffer over and over (so the contents are valid and initialized; they're just stale). We can see demonstrate this by tightening the regex we use to match the error message in t5516; without this patch, git-fetch will accidentally print the capabilities from the (much longer) initial packet we received. By moving the ERR code later in the function we get a few other benefits, too: - we'll now chomp any newline sent by the other side (which is what we want, since die() will add its own newline) - we'll now mention the ERR packet with GIT_TRACE_PACKET Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	014ade7484	upload-pack: send ERR packet for non-tip objects Commit `bdb31eada7` (upload-pack: report "not our ref" to client, 2017-02-23) catches the case where a client asks for an object we don't have, and issues a message that the client can show to the user (in addition to dying and writing to stderr). There's a similar case (with the same message) when the client asks for an object which we _do_ have, but which isn't a ref tip (or isn't reachable, when uploadpack.allowReachableSHA1InWant is true). Let's give that one the same treatment, for the same reason (namely that it's more informative to the client than just hanging up, since they won't see our stderr over some protocols). There are two tests here. We cover it most directly in t5530 by invoking upload-pack, which matches the existing "not our ref" test. But a more end-to-end check is that "git fetch" actually shows the message to the client. We're already checking in t5516 that this case fails, so we can just check stderr there, too. Note that even after we started ignoring SIGPIPE in `8bf4becf0c`, this could in theory still be racy as described in that commit (because we die() on write failures before pumping the connection for any ERR packets). In practice this should be OK for this case. The server will not actually check reachability until it has received our whole group of "want" lines. And since we have no objects in the repository, we won't send any "have" lines, meaning we're always waiting to read the server response. Note also that this case cannot happen in the v2 protocol, since it allows any available object to be requested. However, we don't have to take any steps to protect against the upcoming GIT_TEST_PROTOCOL_VERSION in our tests: - the tests in t5516 would already need to be skipped under v2, and that is covered by `ab0c5f5096` (tests: always test fetch of unreachable with v0, 2019-02-25) - the tests in t5530 invoke upload-pack directly, which will continue to default to v0. Eventually we may have a test setting which uses v2 even for bare upload-pack calls, but we can't override it here until we know what the setting looks like. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jeff King	98024d1cb6	t5516: drop ok=sigpipe from unreachable-want tests We annotated our test_must_fail calls in `8bf4becf0c` (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27) because the abrupt hangup of the server meant that we'd sometimes fail on read() and sometimes get SIGPIPE on write(). But since `143588949c` (fetch: ignore SIGPIPE during network operation, 2019-03-03), we make sure that we end up with a real die(), and our tests no longer need to work around the race. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Johannes Schindelin	f6188dccb7	tests (push): do not abbreviate the `--follow-tags` option We really want to spell out the option in the full form, to avoid any ambiguity that might be introduced by future patches. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Jonathan Tan	ab0c5f5096	tests: always test fetch of unreachable with v0 Some tests check that fetching an unreachable object fails, but protocol v2 allows such fetches. Unset GIT_TEST_PROTOCOL_VERSION so that these tests are always run using protocol v0. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
SZEDER Gábor	165293af3c	tests: send "bug in the test script" errors to the script's stderr Some of the functions in our test library check that they were invoked properly with conditions like this: test "$#" = 2 \|\| error "bug in the test script: not 2 parameters to test-expect-success" If this particular condition is triggered, then 'error' will abort the whole test script with a bold red error message [1] right away. However, under certain circumstances the test script will be aborted completely silently, namely if: - a similar condition in a test helper function like 'test_line_count' is triggered, - which is invoked from the test script's "main" shell [2], - and the test script is run manually (i.e. './t1234-foo.sh' as opposed to 'make t1234-foo.sh' or 'make test') [3] - and without the '--verbose' option, because the error message is printed from within 'test_eval_', where standard output is redirected either to /dev/null or to a log file. The only indication that something is wrong is that not all tests in the script are executed and at the end of the test script's output there is no "# passed all N tests" message, which are subtle and can easily go unnoticed, as I had to experience myself. Send these "bug in the test script" error messages directly to the test scripts standard error and thus to the terminal, so those bugs will be much harder to overlook. Instead of updating all ~20 such 'error' calls with a redirection, let's add a BUG() function to 'test-lib.sh', wrapping an 'error' call with the proper redirection and also including the common prefix of those error messages, and convert all those call sites [4] to use this new BUG() function instead. [1] That particular error message from 'test_expect_success' is printed in color only when running with or without '--verbose'; with '--tee' or '--verbose-log' the error is printed without color, but it is printed to the terminal nonetheless. [2] If such a condition is triggered in a subshell of a test, then 'error' won't be able to abort the whole test script, but only the subshell, which in turn causes the test to fail in the usual way, indicating loudly and clearly that something is wrong. [3] Well, 'error' aborts the test script the same way when run manually or by 'make' or 'prove', but both 'make' and 'prove' pay attention to the test script's exit status, and even a silently aborted test script would then trigger those tools' usual noticable error messages. [4] Strictly speaking, not all those 'error' calls need that redirection to send their output to the terminal, see e.g. 'test_expect_success' in the opening example, but I think it's better to be consistent. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Junio C Hamano	b072a25fad	receive: denyCurrentBranch=updateinstead should not blindly update The handling of receive.denyCurrentBranch=updateInstead was added to a switch statement that handles other values of the variable, but all the other case arms only checked a condition to reject the attempted push, or let later logic in the same function to still intervene, so that a push that does not fast-forward (which is checked after the switch statement in question) is still rejected. But the handling of updateInstead incorrectly took immediate effect, without giving other checks a chance to intervene. Instead of calling update_worktree() that causes the side effect immediately, just note the fact that we will need to call the function later, and first give other checks a chance to reject the request. After the update-hook gets a chance to reject the push (which happens as the last step in a series of checks), call update_worktree() when we earlier detected the need to. Reported-by: Rajesh Madamanchi Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	0bc8d71b99	fetch: stop clobbering existing tags without --force Change "fetch" to treat "+" in refspecs (aka --force) to mean we should clobber a local tag of the same name. This changes the long-standing behavior of "fetch" added in `853a3697dc` ("[PATCH] Multi-head fetch.", 2005-08-20). Before this change, all tag fetches effectively had --force enabled. See the git-fetch-script code in fast_forward_local() with the comment: > Tags need not be pointing at commits so there is no way to > guarantee "fast-forward" anyway. That commit and the rest of the history of "fetch" shows that the "+" (--force) part of refpecs was only conceived for branch updates, while tags have accepted any changes from upstream unconditionally and clobbered the local tag object. Changing this behavior has been discussed as early as 2011[1]. The current behavior doesn't make sense to me, it easily results in local tags accidentally being clobbered. We could namespace our tags per-remote and not locally populate refs/tags/, but as with my `97716d217c` ("fetch: add a --prune-tags option and fetch.pruneTags config", 2018-02-09) it's easier to work around the current implementation than to fix the root cause. So this change implements suggestion #1 from Jeff's 2011 E-Mail[1], "fetch" now only clobbers the tag if either "+" is provided as part of the refspec, or if "--force" is provided on the command-line. This also makes it nicely symmetrical with how "tag" itself works when creating tags. I.e. we refuse to clobber any existing tags unless "--force" is supplied. Now we can refuse all such clobbering, whether it would happen by clobbering a local tag with "tag", or by fetching it from the remote with "fetch". Ref updates outside refs/{tags,heads/ are still still not symmetrical with how "git push" works, as discussed in the recently changed pull-fetch-param.txt documentation. This change brings the two divergent behaviors more into line with one another. I don't think there's any reason "fetch" couldn't fully converge with the behavior used by "push", but that's a topic for another change. One of the tests added in `31b808a032` ("clone --single: limit the fetch refspec to fetched branch", 2012-09-20) is being changed to use --force where a clone would clobber a tag. This changes nothing about the existing behavior of the test. 1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	6b0b0677f6	fetch tests: add a test for clobbering tag behavior The test suite only incidentally (and unintentionally) tested for the current behavior of eager tag clobbering on "fetch". This is a followup to `380efb65df` ("push tests: assert re-pushing annotated tags", 2018-07-31) which tests for it explicitly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	253b3d4f57	push tests: use spaces in interpolated string The quoted -m'msg' option would mean the same as -mmsg when passed through the test_force_push_tag helper. Let's instead use a string with spaces in it, to have a working example in case we need to pass other whitespace-delimited arguments to git-tag. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	f08fb8dfea	push tests: make use of unused $1 in test description Fix up a logic error in `380efb65df` ("push tests: assert re-pushing annotated tags", 2018-07-31), where the $tag_type_description variable was assigned to but never used, unlike in the subsequently added companion test for fetches in 2d216a7ef6 ("fetch tests: add a test for clobbering tag behavior", 2018-04-29). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	380efb65df	push tests: assert re-pushing annotated tags Change the test that asserts that lightweight tags can only be clobbered by a force-push to check do the same tests for annotated tags. There used to be less exhaustive tests for this with the code added in `40eff17999` ("push: require force for annotated tags", 2012-11-29), but Junio removed them in `256b9d70a4` ("push: fix "refs/tags/ hierarchy cannot be updated without --force"", 2013-01-16) while fixing some of the behavior around tag pushing. That change left us without any coverage asserting that pushing and clobbering annotated tags worked as intended. There was no reason to suspect that the receive machinery wouldn't behave the same way with annotated tags, but now we know for sure. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	941a7baa4d	push tests: add more testing for forced tag pushing Improve the tests added in `dbfeddb12e` ("push: require force for refs under refs/tags/", 2012-11-29) to assert that the same behavior applies various other combinations of command-line option and refspecs. Supplying either "+" in refspec or "--force" is sufficient to clobber the reference. With --no-force we still pay attention to "+" in the refspec, and vice-versa with clobbering kicking in if there's no "+" in the refspec but "+" is given. This is consistent with how refspecs work for branches, where either "+" or "--force" will enable clobbering, with neither taking priority over the other. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	25f74f5234	push tests: fix logic error in "push" test assertion Fix a logic error that's been here since this test was added in `dbfeddb12e` ("push: require force for refs under refs/tags/", 2012-11-29). The intent of this test is to force-create a new tag pointing to HEAD~, and then assert that pushing it doesn't work without --force. Instead, the code was not creating a new tag at all, and then failing to push the previous tag for the unrelated reason of providing a refspec that doesn't make any sense. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	76bcde5956	push tests: remove redundant 'git push' invocation Remove an invocation of 'git push' that's exactly the same as the one on the preceding line. This was seemingly added by mistake in `dbfeddb12e` ("push: require force for refs under refs/tags/", 2012-11-29) and doesn't affect the result of the test, the second "push" was a no-op as there was nothing new to push. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	54e934e66d	fetch tests: change "Tag" test tag to "testTag" Calling the test tag "Tag" will make for confusing reading later in this series when making use of the "git push tag <name>" feature. Let's call the tag testTag instead. Changes code initially added in `dbfeddb12e` ("push: require force for refs under refs/tags/", 2012-11-29). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Eric Sunshine	51b85471af	t5000-t5999: fix broken &&-chains Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Jonathan Nieder	6c301adb0a	fetch: do not pass ref-prefixes for fetch by exact SHA1 When v2.18.0-rc0~10^2~1 (refspec: consolidate ref-prefix generation logic, 2018-05-16) factored out the ref-prefix generation code for reuse, it left out the 'if (!item->exact_sha1)' test in the original ref-prefix generation code. As a result, fetches by SHA-1 generate ref-prefixes as though the SHA-1 being fetched were an abbreviated ref name: $ GIT_TRACE_PACKET=1 bin-wrappers/git -c protocol.version=2 \ fetch origin `12039e008f` [...] packet: fetch> ref-prefix `12039e008f` packet: fetch> ref-prefix refs/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/tags/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/heads/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448 packet: fetch> ref-prefix refs/remotes/12039e008f9a4e3394f3f94f8ea897785cb09448/HEAD packet: fetch> 0000 If there is another ref name on the command line or the object being fetched is already available locally, then that's mostly harmless. But otherwise, we error out with fatal: no matching remote head since the server did not send any refs we are interested in. Filter out the exact_sha1 refspecs to avoid this. This patch adds a test to check this behavior that notices another behavior difference between protocol v0 and v2 in the process. Add a NEEDSWORK comment to clear it up. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
brian m. carlson	8125a58b91	t: switch $_z40 to $ZERO_OID Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
SZEDER Gábor	f6b82970aa	t5516-fetch-push: fix broken &&-chain `b2dc968e60` (t5516: refactor oddball tests, 2008-11-07) accidentaly broke the &&-chain in the test 'push does not update local refs on failure', but since it was in a subshell, chain-lint couldn't notice it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
SZEDER Gábor	cfb482b6c3	t5516-fetch-push: fix 'push with dry-run' test In a while-at-it cleanup replacing a 'cd dir && <...> && cd ..' with a subshell, commit `28391a80a9` (receive-pack: allow deletion of corrupt refs, 2007-11-29) also moved the assignment of the $old_commit variable to that subshell. This variable, however, is used outside of that subshell as a parameter of check_push_result(), to check that a ref still points to the commit where it is supposed to. With the variable remaining unset outside the subshell check_push_result() doesn't perform that check at all. Use 'git -C <dir> cmd...', so we don't need to change directory, and thus don't need the subshell either when setting $old_commit. Furthermore, change check_push_result() to require at least three parameters (the repo, the oid, and at least one ref), so it will catch similar issues earlier should they ever arise. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Nguyễn Thái Ngọc Duy	0e496492d2	t/helper: merge test-chmtime into test-tool Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Matt McCutchen	d56583ded6	fetch-pack: add specific error for fetching an unadvertised object Enhance filter_refs (which decides whether a request for an unadvertised object should be sent to the server) to record a new match status on the "struct ref" when a request is not allowed, and have report_unmatched_refs check for this status and print a special error message, "Server does not allow request for unadvertised object". Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Matt McCutchen	e70a65c5d8	fetch_refs_via_pack: call report_unmatched_refs "git fetch" currently doesn't bother to check that it got all refs it sought, because the common case of requesting a nonexistent ref triggers a die() in get_fetch_map. However, there's at least one case that slipped through: "git fetch REMOTE SHA1" if the server doesn't allow requests for unadvertised objects. Make fetch_refs_via_pack (which is on the "git fetch" code path) call report_unmatched_refs so that we at least get an error message in that case. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Pranit Bauva	c7cf956618	don't use test_must_fail with grep test_must_fail should only be used for testing git commands. To test the failure of other commands use `!`. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Elia Pinto	bf45242ba7	t/t5516-fetch-push.sh: use the $( ... ) construct for command substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Lars Schneider	8bf4becf0c	add "ok=sigpipe" to test_must_fail and use it to fix flaky tests t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is flaky in the following case: 1. remote upload-pack finds out "not our ref" 2. remote sends a response and closes the pipe 3. fetch-pack still tries to write commands to the remote upload-pack 4. write call in wrapper.c dies with SIGPIPE The test is flaky because the sending fetch-pack may or may not have finished writing its output by step (3). If it did, then we see a closed pipe on the next read() call. If it didn't, then we get the SIGPIPE from step (4) above. Both are fine, but the latter fools test_must_fail. t5504 "9 - push with transfer.fsckobjects" is flaky, too, and returns SIGPIPE once in a while. I had to remove the final "To dst..." output check because there is no output if the process dies with SIGPIPE. Accept such a death-with-sigpipe also as OK when we are expecting a failure. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net>	9 years ago
Fredrik Medley	68ee628932	upload-pack: optionally allow fetching reachable sha1 With uploadpack.allowReachableSHA1InWant configuration option set on the server side, "git fetch" can make a request with a "want" line that names an object that has not been advertised (likely to have been obtained out of band or from a submodule pointer). Only objects reachable from the branch tips, i.e. the union of advertised branches and branches hidden by transfer.hideRefs, will be processed. Note that there is an associated cost of having to walk back the history to check the reachability. This feature can be used when obtaining the content of a certain commit, for which the sha1 is known, without the need of cloning the whole repository, especially if a shallow fetch is used. Useful cases are e.g. repositories containing large files in the history, fetching only the needed data for a submodule checkout, when sharing a sha1 without telling which exact branch it belongs to and in Gerrit, if you think in terms of commits instead of change numbers. (The Gerrit case has already been solved through allowTipSHA1InWant as every Gerrit change has a ref.) Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	1a51b52422	push-to-deploy: allow pushing into an unborn branch and updating it Setting receive.denycurrentbranch to updateinstead and pushing into the current branch, when the working tree and the index is truly clean, is supposed to reset the working tree and the index to match the tree of the pushed commit. This did not work when pushing into an unborn branch. The code that drives push-to-checkout hook needs no change, as the interface is defined so that hook can decide what to do when the push is coming to an unborn branch and take an appropriate action since the beginning. Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Jeff King	c3c17bf107	filter_ref: make a copy of extra "sought" entries If the server supports allow_tip_sha1_in_want, we add any unmatched raw-sha1 entries in our "sought" list of refs to the list of refs we will ask the other side for. We do so by inserting the original "struct ref" directly into our list, rather than making a copy. This has several problems. The most minor problem is that one cannot ever free the resulting list; it contains structs that are copies of the remote refs (made earlier by fetch_pack) along with sought refs that are referenced elsewhere. But more importantly that we set the ref->next pointer to NULL, chopping off the remainder of any existing list that the ref was a part of. We get the set of "sought" refs in an array rather than a linked list, but that array is often in turn generated from a list. The test modification in t5516 demonstrates this. Rather than fetching just an exact sha1, we fetch that sha1 plus another ref: - we build a linked list of refs to fetch when do_fetch calls get_ref_map; the exact sha1 is first, followed by the named ref ("refs/heads/extra" in this case). - we pass that linked list to transport_fetch_ref, which squashes it into an array of pointers - that array goes to fetch_pack, which calls filter_ref. There we generate the want list from a mix of what the remote side has advertised, and the "sought" entry for the exact sha1. We set the sought entry's "next" pointer to NULL. - after we return from transport_fetch_refs, we then try to update the refs by following the linked list. But our list is now truncated, and we do not update refs/heads/extra at all. We can fix this by making a copy of the ref. There's nothing that fetch_pack does to it that must be reflected in the original "sought" list (and indeed, if that were the case we would have a serious bug, because it is only exact-sha1 entries which are treated this way). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Anders Kaseorg	eb32c66e8d	t5516: correct misspelled pushInsteadOf A future breakage to "git push" to make it incorrectly pay attention to pushInsteadOf when it should not will be left uncaught without this change. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	0855331941	receive-pack: support push-to-checkout hook When receive.denyCurrentBranch is set to updateInstead, a push that tries to update the branch that is currently checked out is accepted only when the index and the working tree exactly matches the currently checked out commit, in which case the index and the working tree are updated to match the pushed commit. Otherwise the push is refused. This hook can be used to customize this "push-to-deploy" logic. The hook receives the commit with which the tip of the current branch is going to be updated, and can decide what kind of local changes are acceptable and how to update the index and the working tree to match the updated tip of the current branch. For example, the hook can simply run `git read-tree -u -m HEAD "$1"` in order to emulate 'git fetch' that is run in the reverse direction with `git push`, as the two-tree form of `read-tree -u -m` is essentially the same as `git checkout` that switches branches while keeping the local changes in the working tree that do not interfere with the difference between the branches. Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Junio C Hamano	4d7a5ceacc	t5516: more tests for receive.denyCurrentBranch=updateInstead The previous one tests only the case where a path to be updated by the push-to-deploy has an incompatible change in the target's working tree that has already been added to the index, but the feature itself wants to require the working tree to be a lot cleaner than what is tested. Add a handful more tests to protect the feature from future changes that mistakenly (from the viewpoint of the inventor of the feature) loosens the cleanliness requirement, namely: - A change only to the working tree but not to the index is still a change to be protected; - An untracked file in the working tree that would be overwritten by a push-to-deploy needs to be protected; - A change that happens to make a file identical to what is being pushed is still a change to be protected (i.e. the feature's cleanliness requirement is more strict than that of checkout). Also, test that a stat-only change to the working tree is not a reason to reject a push-to-deploy. Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Johannes Schindelin	1404bcbb6b	receive-pack: add another option for receive.denyCurrentBranch When synchronizing between working directories, it can be handy to update the current branch via 'push' rather than 'pull', e.g. when pushing a fix from inside a VM, or when pushing a fix made on a user's machine (where the developer is not at liberty to install an ssh daemon let alone know the user's password). The common workaround – pushing into a temporary branch and then merging on the other machine – is no longer necessary with this patch. The new option is: 'updateInstead': Update the working tree accordingly, but refuse to do so if there are any uncommitted changes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	10 years ago
Jeff King	72549dfd5d	fetch: load all default config at startup When we start the git-fetch program, we call git_config to load all config, but our callback only processes the fetch.prune option; we do not chain to git_default_config at all. This means that we may not load some core configuration which will have an effect. For instance, we do not load core.logAllRefUpdates, which impacts whether or not we create reflogs in a bare repository. Note that I said "may" above. It gets even more exciting. If we have to transfer actual objects as part of the fetch, then we call fetch_pack as part of the same process. That function loads its own config, which does chain to git_default_config, impacting global variables which are used by the rest of fetch. But if the fetch is a pure ref update (e.g., a new ref which is a copy of an old one), we skip fetch_pack entirely. So we get inconsistent results depending on whether or not we have actual objects to transfer or not! Let's just load the core config at the start of fetch, so we know we have it (we may also load it again as part of fetch_pack, but that's OK; it's designed to be idempotent). Our tests check both cases (with and without a pack). We also check similar behavior for push for good measure, but it already works as expected. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Jeff King	458a7e508c	t5516: test pushing a tag of an otherwise unreferenced blob It's not unreasonable to have a tag that points to a blob that is not part of the normal history. We do this in git.git to distribute gpg keys. However, we never explicitly checked in our test suite that this actually works (i.e., that pack-objects actually sends the blob because of the tag mentioning it). It does in fact work fine, but a recent patch under discussion broke this, and the test suite didn't notice. Let's make the test suite more complete. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Jeff King	98b406f3ad	remote: handle pushremote config in any order The remote we push can be defined either by remote.pushdefault or by branch.*.pushremote for the current branch. The order in which they appear in the config file should not matter to precedence (which should be to prefer the branch-specific config). The current code parses the config linearly and uses a single string to store both values, overwriting any previous value. Thus, config like: [branch "master"] pushremote = foo [remote] pushdefault = bar erroneously ends up pushing to "bar" from the master branch. We can fix this by storing both values and resolving the correct value after all config is read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Junio C Hamano	fc9261ca61	push: also use "upstream" mapping when pushing a single ref When the user is using the 'upstream' mode, these commands: $ git push $ git push origin would find the 'upstream' branch for the current branch, and then push the current branch to update it. However, pushing a single branch explicitly, i.e. $ git push origin $(git symbolic-ref --short HEAD) would not go through the same ref mapping process, and ends up updating the branch at 'origin' of the same name, which may not necessarily be the upstream of the branch being pushed. In the spirit similar to the previous one, map a colon-less refspec using the upstream mapping logic. Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Junio C Hamano	ca02465b41	push: use remote.$name.push as a refmap Since `f2690487` (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/:refs/remotes/origin/ to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/:refs/remotes/satellite/ on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/:refs/remotes/satellite/ on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Nguyễn Thái Ngọc Duy	f7c815c3ee	push: respect --no-thin - From the beginning of push.c in `755225d`, 2006-04-29, "thin" option was enabled by default but could be turned off with --no-thin. - Then Shawn changed the default to 0 in favor of saving server resources in `a4503a1`, 2007-09-09. --no-thin worked great. - One day later, in `9b28851` Daniel extracted some code from push.c to create transport.c. He (probably accidentally) flipped the default value from 0 to 1 in transport_get(). From then on --no-thin is effectively no-op because git-push still expects the default value to be false and only calls transport_set_option() when "thin" variable in push.c is true (which is unnecessary). Correct the code to respect --no-thin by calling transport_set_option() in both cases. receive-pack learns about --reject-thin-pack-for-testing option, which only is for testing purposes, hence no document update. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Ramkumar Ramachandra	9f765ce62f	remote.c: introduce branch.<name>.pushremote This new configuration variable overrides `remote.pushdefault` and `branch.<name>.remote` for pushes. When you pull from one place (e.g. your upstream) and push to another place (e.g. your own publishing repository), you would want to set `remote.pushdefault` to specify the remote to push to for all branches, and use this option to override it for a specific branch. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Ramkumar Ramachandra	224c217163	remote.c: introduce remote.pushdefault This new configuration variable defines the default remote to push to, and overrides `branch.<name>.remote` for all branches. It is useful in the typical triangular-workflow setup, where the remote you're fetching from is different from the remote you're pushing to. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Jeff King	2e433b7895	t5516 (fetch-push): drop implicit arguments from helper functions Many of the tests in t5516 look like: mk_empty && git push testrepo ... && check_push_result $commit heads/master It's reasonably easy to see what is being tested, with the exception that "testrepo" is a magic global name (it is implicitly used in the helpers, but we have to name it explicitly when calling git directly). Let's make it explicit when call the helpers, too. This is slightly more typing, but makes the test snippets read more naturally. It also makes it easy for future tests to use an alternate or multiple repositories, without a proliferation of helper functions. [rr: fixed sloppy quoting] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Ramkumar Ramachandra	2ead7a674d	t5516 (fetch-push): update test description The file was originally created in `bcdb34f` (Test wildcard push/fetch, 2007-06-08), and only contained tests that exercised wildcard functionality at the time. In subsequent commits, many other tests unrelated to wildcards were added but the test description was never updated. Fix this. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago
Junio C Hamano	c68c408a7a	t5516: test interaction between pushURL and pushInsteadOf correctly `1c2eafb89b` (Add url.<base>.pushInsteadOf: URL rewriting for push only, 2009-09-07) wants to make sure that a push destination read from URL is not rewritten by pushInsteadOf because an explicit pushURL exists; for that, a pushInsteadOf rewrite rule for the value of remote.r.URL is set to a non-existent is set up. We would also want to make sure that pushInsteadOf rewrite rule is not applied to the location read from pushURL. This way, we will make sure that - "testrepo/" (pushURL) gets updated; - the push does not try to update "trash2/" (the result of applying pushInsteadOf to pushURL); - the push does not try to update "trash3/" (the result of applying pushInsteadOf to URL). Signed-off-by: Junio C Hamano <gitster@pobox.com>	12 years ago

1 2 3

129 Commits (5602b500c3cd9ac308bf9af0d5f0a79bd2195346)