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

From: Junio C Hamano <junkio@cox.net>
Date: Apr 6, 2007, 21:44 UTC
Message-ID: <7vbqi1jhzx.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070406025255.GA31909@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

> 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.