Felipe Contreras [off-list ref] writes:
So it should be clear now: the remote namespace refs/origin/master is
updated, but not the remote helper's namespace
refs/testgit/origin/master, which is what I already said. I don't know
what more do you expect. When you push 'refs/heads/master' to origin,
you expect 'refs/remotes/origin/master' to point to the same commit,
same with 'refs/testgit/origin/master', why would you expect to point
somewhere else?
Let me play somebody who comes later and wonders about this exchange
three months down the road...
You mention three refs/ here. Do they live in the same repository?
Any Git person is expected to know refs/heads/master, which is "my
local branch I have worked on and I am pushing". It also is easy to
guess what "refs/remotes/origin/master" is, even though we are not
talking about a usual Git remote. It is to keep track of the remote
behind the helper we are pushing into, and is updated to pretend as
if we fetched immediately from the place we just pushed. The latter
being in sync with what we pushed is something that can naturally be
expected.
Now, what is this third "refs/testgit/origin/master" thing? Is it
expected to always be the same as "refs/remotes/origin/master"? If
that is the case, why do we even need such a redundant information
in the first place?
On Mon, Apr 15, 2013 at 11:12 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
So it should be clear now: the remote namespace refs/origin/master is
updated, but not the remote helper's namespace
refs/testgit/origin/master, which is what I already said. I don't know
what more do you expect. When you push 'refs/heads/master' to origin,
you expect 'refs/remotes/origin/master' to point to the same commit,
same with 'refs/testgit/origin/master', why would you expect to point
somewhere else?
Let me play somebody who comes later and wonders about this exchange
three months down the road...
You mention three refs/ here. Do they live in the same repository?
Any Git person is expected to know refs/heads/master, which is "my
local branch I have worked on and I am pushing". It also is easy to
guess what "refs/remotes/origin/master" is, even though we are not
talking about a usual Git remote. It is to keep track of the remote
behind the helper we are pushing into, and is updated to pretend as
if we fetched immediately from the place we just pushed. The latter
being in sync with what we pushed is something that can naturally be
expected.
Now, what is this third "refs/testgit/origin/master" thing? Is it
expected to always be the same as "refs/remotes/origin/master"? If
that is the case, why do we even need such a redundant information
in the first place?
Answering that question is beyond the scope of the commit message. The
purpose of the commit message is not to educate people about the
current design of transport-helpers, we have
Documentation/gitremote-helpers.txt for that. We also have discussions
in the mailing list.
The untold answer is 'if you have to ask, you don't understand this
code', but if you must, the short answer is: because it doesn't work
otherwise.
Yes, in theory not using a remote helper ref namespace should work,
but it doesn't, and I sent patches to try to fix this behavior, but
those, along with this particular patch, where ignored. So I gave up
on those patches that tried to fix the behavior for more corner cases
and tried to push the simplest one I could find, still finding
trouble. I tried to document that in t/t5801-remote-helpers.sh,
although to be honest, the tests that pass can be hardly be considered
proper behavior. This is of course, for import/export, which are the
only operations I'm familiar with (maybe the namespace makes sense for
push/fetch operations.
So basically I'm just tired of explaining the same things over and
over again, and if you try to explain every single detail, I think any
reasonable person would reach the conclusion that the design doesn't
really make sense. But the only person that seems to be trying to
explain it and improve it seems to be me.
The commit message is no place to explain all these subtleties, it
would be huge and would need to refer to plenty of mails in the
mailing list.
I could send the whole patch series I have, and then it might become
clearer why not having the refspec doesn't work, but then ,the chances
of this patch not getting through would be higher, as the last time I
sent such series, it didn't go through.
Cheers.
--
Felipe Contreras