Re: [PATCH v4 1/2] negative-refspec: fix segfault on : refspec

[Junio C Hamano <gitster@pobox.com>]

"Nipunn Koorapati via GitGitGadget" <gitgitgadget@gmail.com> 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