git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Yuri Kanivetsky <yuri.kanivetsky@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: remote.<name>.push without dst doesn't behave as documented
Date: Mon, 16 Dec 2024 10:12:09 -0800	[thread overview]
Message-ID: <xmqqr0674hvq.fsf@gitster.g> (raw)
In-Reply-To: <CAMhVC3b+1TWLkKGYVb6VyBRyQjsDpbKRQQNT8SUXSmrWHfPnEQ@mail.gmail.com> (Yuri Kanivetsky's message of "Mon, 16 Dec 2024 18:47:28 +0200")

Yuri Kanivetsky <yuri.kanivetsky@gmail.com> 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.

  reply	other threads:[~2024-12-16 18:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 16:47 remote.<name>.push without dst doesn't behave as documented Yuri Kanivetsky
2024-12-16 18:12 ` Junio C Hamano [this message]
2024-12-17  8:12   ` Yuri Kanivetsky
2024-12-19  3:48     ` Yuri Kanivetsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr0674hvq.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=yuri.kanivetsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).