"Nipunn Koorapati via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > +test_expect_success "push with matching : and negative refspec" ' > + test_config -C two remote.one.push : && > + # Fails to push master w/ tip behind counterpart > + test_must_fail git -C two push one && I offhand do not know where the master branch of two and one repositories are, but I presume that one's master is not an ancestor of two's master here, and the reason why this fails is because we would prevent such a non-ff push unless forced? Are there other matching refs between one and two that are subject to the push operation here, or is the 'master' the only thing that exists? > + # If master is in negative refspec, then the command will not attempt > + # to push and succeed. > + # We do not need test_config here as we are updating remote.one.push > + # again. The teardown of the first test_config will do --unset-all > + git -C two config --add remote.one.push ^refs/heads/master && > + git -C two push one ... and the idea of the test is that by adding a "we do not want to push out our master" configuration, we no longer attempt to push out the 'master' branch from two that is not a descendant of the master branch of one, so "push" would "succeed". Is there other branches involved, or this is essentially a no-op as there is only 'master' branch involved in the operation? > +' > + > +test_expect_success "push with matching +: and negative refspec" ' > + test_config -C two remote.one.push +: && > + # Fails to push master w/ tip behind counterpart > + test_must_fail git -C two push one && Assuming that the successful case from the previous test was a no-op, we start from the same condition from the previous one. THe only difference is that the matching push is now configured to force. So, how would this one fail, exactly? Aren't we forcing? Shouldn't we succeed in such a case? I think the test still fails to push but for a different reason. It is not because the tip being pushed is not ahead of the counterpart at the receiving repository. +: (i.e. force-push matching refs) takes care of the "must fast-forward" requirement that causes the previous one to fail. It is because the receiving repository is not a bare repository, and the push attempts to update its current branch. It cannot be forced with + prefix, and that is why it fails. So, the comment above is wrong. Perhaps # Fail to update the branch currently checked out. or something. > + # If master is in negative refspec, then the command will not attempt > + # to push and succeed > + git -C two config --add remote.one.push ^refs/heads/master && > + git -C two push one And this succeeds for the same reason, i.e. it becomes no-op because there is no other branches involved? > +' > + > test_done Ideally, we should make sure that the next person who reads "git show" output of the commit that would result from the patch would not have to ask any of the "?" asked in the review above. Let me see if I can come up with a suggestion to get us closer to that goal. ... goes and hacks ... Perhaps squash the following into this step? Thanks. t/t5582-fetch-negative-refspec.sh | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git c/t/t5582-fetch-negative-refspec.sh w/t/t5582-fetch-negative-refspec.sh index a4960c586b..bed67cf92d 100755 --- c/t/t5582-fetch-negative-refspec.sh +++ w/t/t5582-fetch-negative-refspec.sh @@ -187,8 +187,13 @@ test_expect_success "fetch --prune with negative refspec" ' ' test_expect_success "push with matching : and negative refspec" ' + # Repositories two and one have branches other than master" + # but they have no overlap---"master" is the only one that + # is shared between them. And the master branch at two is + # behind the master branch at one by one commit. test_config -C two remote.one.push : && - # Fails to push master w/ tip behind counterpart + + # A matching push tries to update master, fails due to non-ff test_must_fail git -C two push one && # If master is in negative refspec, then the command will not attempt @@ -196,18 +201,27 @@ test_expect_success "push with matching : and negative refspec" ' # We do not need test_config here as we are updating remote.one.push # again. The teardown of the first test_config will do --unset-all git -C two config --add remote.one.push ^refs/heads/master && - git -C two push one + + # With "master" excluded, this push is a no-op. Nothing gets + # pushed and it succeeds. + git -C two push -v one ' test_expect_success "push with matching +: and negative refspec" ' + # The same set-up as above, whose side-effect was a no-op. test_config -C two remote.one.push +: && - # Fails to push master w/ tip behind counterpart + + # The push refuses to update the "master" branch that is checked + # out in the "one" repository, even when it is forced with +: test_must_fail git -C two push one && # If master is in negative refspec, then the command will not attempt # to push and succeed git -C two config --add remote.one.push ^refs/heads/master && - git -C two push one + + # With "master" excluded, this push is a no-op. Nothing gets + # pushed and it succeeds. + git -C two push -v one ' test_done
