* remote.<name>.push without dst doesn't behave as documented
@ 2024-12-16 16:47 Yuri Kanivetsky
2024-12-16 18:12 ` Junio C Hamano
0 siblings, 1 reply; 4+ messages in thread
From: Yuri Kanivetsky @ 2024-12-16 16:47 UTC (permalink / raw)
To: Git Mailing List
Hi,
> 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>.
https://git-scm.com/docs/git-push#Documentation/git-push.txt-ltrefspecgt82308203
The only case I can think of where refspec is not passed via command
line and it updates a non-matching branch is when push.default =
upstream. But with remote.<repository>.push without dst it starts
updating a matching branch. Either I don't understand what's meant, or
it doesn't behave as documented.
The second test fails:
@test "normally a non-matching ref updates" {
start_cloned_repo
git config push.default upstream
git checkout -b bb
git branch -u origin/ba
git commit --allow-empty -m b
git push
assert_equal_refs origin/ba bb
}
@test "with remote.<name>.push without dst happens what happens normally" {
start_cloned_repo
git config push.default upstream
git config remote.origin.push 'refs/heads/*'
git checkout -b bb
git branch -u origin/ba
git commit --allow-empty -m b
git push
assert_equal_refs origin/ba bb
}
start_cloned_repo() {
(mkrepo)
cd "$BATS_TEST_TMPDIR"
git clone --bare a a.git
git clone a.git b
cd b
git config push.default upstream
git config user.email you@example.com
git config user.name "Your Name"
}
mkrepo() {
cd "$BATS_TEST_TMPDIR"
mkdir a
(cd a
git init
git branch -m ba
git config user.email you@example.com
git config user.name "Your Name"
git commit --allow-empty -m a)
}
More details in a gist:
https://gist.github.com/x-yuri/943fd13704b38551da36c8363d7852e1
Regards,
Yuri
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: remote.<name>.push without dst doesn't behave as documented
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
2024-12-17 8:12 ` Yuri Kanivetsky
0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2024-12-16 18:12 UTC (permalink / raw)
To: Yuri Kanivetsky; +Cc: Git Mailing List
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: remote.<name>.push without dst doesn't behave as documented
2024-12-16 18:12 ` Junio C Hamano
@ 2024-12-17 8:12 ` Yuri Kanivetsky
2024-12-19 3:48 ` Yuri Kanivetsky
0 siblings, 1 reply; 4+ messages in thread
From: Yuri Kanivetsky @ 2024-12-17 8:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
So it was your doing :) (no offense meant)
https://github.com/git/git/commit/ca02465b41311fe7634acb9bb5b5c61975ef5f38
> 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>.
My understanding of this was (the only phrasing that made some sense to me):
> If git push [<repository>] without any <refspec> argument __is invoked__ to update some ref at the destination with <src> __and remote.<repository>.push is set__, :<dst> part can be omitted __in remote.<repository>.push__ -- 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>.
As such I chose `push.default = upstream` because that's the only mode
which allows non-matching refs. I expected it to allow me to
discriminate between having and not having :dst in
remote.<repository>.push. But without :dst in remote.<repository>.push
it updated the matching ref (the second test failed).
Now I understand that what was really meant:
> If remote.<repository>.push is set and the refspec on the command line doesn't have the :dst part, then the former (remote.<repository>.push) is used as a refmap. Otherwise (if remote.<repository>.push is not set), then missing :dst makes it push to the matching branch.
I believe the phrasing in the documentation calls for being changed.
But also I can't confirm the "otherwise" part. Below the last test
fails. Either you have to (unless I'm missing something) say:
> If remote.<repository>.push is not set, then it falls back to the `push.default` behavior.
Or make it really push to the matching branch even if `push.default =
upstream` and the upstream is a non-matching branch.
Regards,
Yuri
--
The whole file is in a gist:
https://gist.github.com/x-yuri/943fd13704b38551da36c8363d7852e1#file-b-md
# the state of the cloned repository (1 commit, 1 local branch ba)
# a (HEAD -> ba, origin/ba)
@test "normally it acts according to push.default" {
start_cloned_repo
git commit --allow-empty -m b
git push
assert_equal_refs origin/ba ba
}
@test "but remote.<repository>.push changes the destination when the
refspec on the command line doesn't have :dst" {
start_cloned_repo
git config remote.origin.push 'refs/heads/ba:refs/heads/bb'
git commit --allow-empty -m b
git push origin ba
assert_equal_refs origin/bb ba
}
@test "specifying :dst overrides remote.<repository>.push" {
start_cloned_repo
git config remote.origin.push 'refs/heads/*:refs/heads/*'
git commit --allow-empty -m b
git push origin ba:bb
assert_equal_refs origin/bb ba
}
@test "if remote.<repository>.push is not set, it pushes to the
matching branch" {
start_cloned_repo
git config push.default upstream
git push origin ba:bb
git branch -u origin/bb
git commit --allow-empty -m b
git push origin ba
assert_equal_refs origin/ba ba
}
start_cloned_repo() {
(mkrepo)
cd "$BATS_TEST_TMPDIR"
git clone --bare a a.git
git clone a.git b
cd b
git config user.email you@example.com
git config user.name "Your Name"
}
mkrepo() {
cd "$BATS_TEST_TMPDIR"
mkdir a
(cd a
git init
git branch -m ba
git config user.email you@example.com
git config user.name "Your Name"
git commit --allow-empty -m a)
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: remote.<name>.push without dst doesn't behave as documented
2024-12-17 8:12 ` Yuri Kanivetsky
@ 2024-12-19 3:48 ` Yuri Kanivetsky
0 siblings, 0 replies; 4+ messages in thread
From: Yuri Kanivetsky @ 2024-12-19 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
I guess I need to add, that I hoped that the beginning would be taken
as a joke. If it wasn't the case, then sorry :( I didn't mean to
offend anyone.
Regards,
Yuri
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-12-19 3:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2024-12-17 8:12 ` Yuri Kanivetsky
2024-12-19 3:48 ` Yuri Kanivetsky
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).