Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> IOW, the notion of "remote" refs really logically implies a mirror image,
> exactly like you have it set up in your config: what is a local ref in one
> repository is a remote ref in another. But that's not what the default
> "git push" semantics are: it just matches refs directly, without that
> mirroring.
>
> And the _reason_ for it doing that are obviously historical: we didn't use
> to have the notion of "remotes", so back when I did that, it made sense.
> It just doesn't make sense any more.
There are two aspects of this issue. If "matching refs"
semantics makes sense, and if pushing refs/remotes makes sense.
I think the above description risks confusing new people by
sounding as if you are saying no to the former question.
"Pushing to the ref of the same path" makes _PERFECT_ sense even
today for a push into a bare repository used for publishing.
It only is not the right thing to do 50% of the time when you
are pushing into a live repository.
And I everyday use an example of why "matching refs" makes sense
for the other 50% of "push into a live repository" case. When I
work on git.git, the second-from-final step every day is to push
into a live repository I have at k.org for final build in an
environment different from what I use for development. I do
"matching refs" push, go there and "git reset --hard" to update
the working tree to build all four branches (there is the issue
that I am too lazy to install receive-pack hook in the live
repository to do that reset --hard to sync the working tree for
me, but that is a separate issue).
So it is not like "matching refs" is always wrong. It is wrong
in some cases, and is perfectly good in some other cases.
What does not make sense AT ALL is to push what you keep under
refs/remotes/ to outside. This issue actually has existed from
the very beginning, and we had a specific instruction that said
"remove 'refs/heads/origin' from your published repository
otherwise you will confuse yourself with push". This was before
separate-remote layout was invented and refs/heads/origin was
the remote tracking branch for the 'master' at the other side.
Back when you did the original "send-pack", there was nothing
outside of refs/{heads,tags}, so historically it made sense to
say "ALL matching", but even then we had to be careful about
'heads/origin'. Now it does not make sense anymore(I am saying
that not-renaming is OK but sending refs/remotes is Bad, which
is quite different from what you said).
Probably we should not do push anything other than refs/heads/
when we do "matching refs"
I think what we might want to do around this area are:
- Don't change anything, if the command line says refspec, or
the remote has push refspec specified.
- When doing 'matching refs', do it only under refs/heads/.
- Ship with a receive-pack hook that attempts a 3-way merge
update when the currently checked out branch is updated.
Additionally we can give an option to "git clone" (or "git
remote add") to arrange the cross-push configuration for
mothership-satellite Andy showed in the clone's .git/config;
but I think that is a separate issue.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
