Re: How can git pull be up-to-date and git push fail?

Jeff King [off-list ref] writes:

On Thu, Apr 05, 2007 at 02:18:58PM -0700, Junio C Hamano wrote:

quoted

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.