All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Alexey I. Froloff" <raorn@altlinux.org>
Cc: git@vger.kernel.org
Subject: Re: most annoying thing in git-push
Date: Mon, 22 Jun 2009 23:08:46 -0700	[thread overview]
Message-ID: <7vd48va3dd.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20090622192147.GE5743@altlinux.org> (Alexey I. Froloff's message of "Mon\, 22 Jun 2009 23\:21\:47 +0400")

"Alexey I. Froloff" <raorn@altlinux.org> writes:

> Is is possible to add such functionality to git-push, so it will
> push tags that point at objects that were uploaded to the remote
> repository?

I think it is doable, because the protocol is for the receiver to first
advertise all its existing refs, which means that the sender can learn
what is missing by first enumerating the tags it has, subtracting what the
receiver has, and then computing the ones that are missing from the
receiver and are reachable from the commits it is pushing, before the
sender has to respond which refs it wants to update with what object and
then send the packfile to transfer necessary objects.  You do not need to
change the protocol, nor what the receiving side does, to implement it.
You only need to update what the push side does.

It however is entirely a different matter if it is a sensible thing to do.

Often, a fetch is made from a public distribution point, which by
definition has only branches and tags that are meant for public
consumption.  It makes sense to auto-follow tags by default.

On the other hand, a push is almost always made from a private working
repository to a public distribution point, in order to update the latter
with only refs and objects meant for public consumption.  A developer
working in such a private working repository will use tags that are not
meant for public consumption while developing, and pushing all tags that
are reachable from the commits that are being pushed out to the public
distribution point is not necessarily desirable, as it will push out many
tags that are only private to the working repository.

It certainly is not a sensible default behaviour, even though it might be
handy as an option for special cases.

  parent reply	other threads:[~2009-06-23  6:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-22 19:21 most annoying thing in git-push Alexey I. Froloff
2009-06-23  5:21 ` ZoltánFüzesi
2009-06-23  6:08 ` Junio C Hamano [this message]
2009-06-23  8:12   ` Jakub Narebski
2009-06-23 15:20   ` Alexey I. Froloff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd48va3dd.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=raorn@altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.