Yuri Kanivetsky <yuri.kanivetsky@xxxxxxxxx> writes:
>> If git push [<repository>] without any <refspec> argument is set
>> to update some ref at the destination with <src> with
>> remote.<repository>.push configuration variable, :<dst> part can
>> be omitted—such a push will update a ref that <src> normally
>> updates without any <refspec> on the command line. Otherwise,
>> missing :<dst> means to update the same ref as the <src>.
This excerpt is for <refspec>... arguments that are given on the
command line, e.g., the command line would look like
$ git push origin smart
However, if we look at the command sequnce you gave,
> ...
> The second test fails:
>
> @test "normally a non-matching ref updates" {
> ...
> git push
> ...
> }
>
> @test "with remote.<name>.push without dst happens what happens normally" {
> ...
> git push
> ...
> }
neither of the above "git push" invocations have <refspec>... on the
command line. So the rules you quoted would not apply to the above
two "git push" invocations, wouldn't it?
In
$ git push origin smart
a <refspec> "smart" is given, but "smart" lacks ":<dst>" part and
only has <src> that is "smart", typically local branch "smart", iow,
"refs/heads/smart".
The paragraph you quoted describes what happens with that command is
designed to be similar to what "git push origin" without any
<refspec> arguments does wrt the given <src> ref.
For example, if
$ git push origin
is set to update some ref on the other side with "smart", "git push
origin smart" would update the same ref on the other side. e.g., if
you have
[remote "origin"]
push = refs/heads/*:refs/remotes/satellite/*
which would normally cause "git push origin" to use refs/heads/smart
to update refs/remotes/satellite/smart, then
$ git push origin smart
would do the same thing, i.e. send "refs/heads/smart" to
"refs/remotes/satellite/smart" on the other side. If your "git push
origin" is configured to do the matching push, "git push origin
master" would update their "refs/heads/master" with ours, because
that is what "git push origin" would do to our "master". That is
what the paragraph you quoted describes, I think.
Now, the command may behave differently from how we described in the
documentation when you did give <refspec> from the command line, and
in that case you may have found a bug. But I do not think the @test
things you had in your report triggers the paragraph you quoted from
the documentation, so would not demonstrate a bug in there.
Thanks.
