Jeff King <peff@xxxxxxxx> writes:
> On Thu, Apr 05, 2007 at 02:18:58PM -0700, Junio C Hamano wrote:
>
>> IIRC "git push" without explicit refspecs push the matching
>> refs, but I am a bit under the weather and feverish, so don't
>> take my word literally but look at git-push manual page please.
>
> Ah, yes you're right. It really doesn't make sense to push
> refs/remotes/* in most cases, since they're just tracking branches, and
> if the destination _does_ have them, then it is unlikely to be in sync
> with you (leading to Bill's problem). OTOH, you might want to be able
> to push them explicitly if you are doing a strict mirror of a
> repository.
>
> The patch below turns off refs/remotes/ sending for "git-push" and
> "git-push --all", but still allows "git-push origin
> remotes/origin/master". I'm not sure about the semantics; maybe --all
> should imply even remotes?
The behaviour of git-send-pack that pushes all the matching refs
made sense when there was no separate-remotes layout (and there
was no "git push" wrapper). Back then, the expected use was
really:
* For integrators who own public repositories, send-pack to
their public repositories without refspecs updated what they
already decided to publish in refs/heads and refs/tags.
Updating refs/tags hierarchy means moving tags which should
have done with caution (since it changes the general public's
view of what the version v2.6.12 really is), but no one can
update tag without first forcing with "git tag -f" in one's
own repository to begin with, it was not a problem in
practice.
* For people who used pull/push with a central repository as
the CVS-style synchronization point, the central repository,
being the mother of all participant repositories, was
supposed to lack the 'origin' branch, and participant
repositories had 'origin' that tracked 'master' of the
central repository. So matching push never needed to worry
about 'origin', and 'master' of participant was pushed to
'master' of the central repository, undergoing the usual
fast-forward checks and all.
Even here, we had a few trouble reports from people who
primed their central repository by cloning from somewhere
(and cloning without --bare) and left the 'origin' branch
around. We might have added instruction to our documentation
that tells people to remove 'origin' branch from their
central repositories to avoid confusion (but I am too lazy to
look).
* For anybody who has more than one private repositories
(e.g. mothership and notebook) and uses push between them
when switching repositories to work in, new development might
have been on a new branch, in which case it needed an
explicit refspec to send the new branch or tag. But
"matching refs" rule was useful for heads most of the time,
as long as the two repositories were reasonably in sync
(e.g. after supper you sit on your couch working on notebook,
and you finish the day by pushing matching refs to your
mothership to prepare for tomorrow, which you would start on
your mothership machine).
In all these cases, what we meant by "matching refs" rule is to
update matching branch heads. Even pushing matching tags is
debatable, as consciously replacing a tag that was already
pushed out with a new one is already a special case, and I would
suspect that replacing a public tag should be done via an
explicit "git send-pack $url tag v2.6.12", even though the
"matching refs" rule would silently update it.
People who built git-send-pack did not use separate remotes
layout (which has not been even invented yet), nor StGIT, so
refs/remotes, refs/bases nor refs/patches were not even on the
radar. Speaking of StGIT, I do not think it makes sense to sync
only .git/refs/{bases,patches} without sending .git/patches.
> Does this seem like a sane direction to take? It just seems silly to be
> pushing refs/remotes, which 99% of the time should be a purely local
> thing.
So I'd suspect "git push" (not limited to git-send-pack) without
explicit refspecs should only do "matching branch heads" these
days, to keep the original spirit but yet to adjust to today's
reality. In other words, instead of treating remotes/ specially
(in a negative sense), like your patch does, I think we should
do only "matching refs in heads/" hierarchy.
-
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