All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH 4/5] Add --remote option to send-pack
Date: Sun, 29 Apr 2007 02:10:06 -0400	[thread overview]
Message-ID: <20070429061006.GU5942@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0704290152410.28708@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> wrote:
> We're not pretending anything; remote has confirmed that the head that the 
> ref tracks has a particular new value (which we provided), so we should be 
> able to update the tracking ref to that value. I don't think it's 
> particularly important that we came by this information in the course of 
> an exchange that wasn't a fetch.

s/remote has confirmed/remote has claimed/

The only way to know the remote really did remember that
refs/heads/foo is now at 3c1718... is to perform some sort of
operation against it that makes it dump its refs back.  Trying to
push again, or trying to fetch does that.

There is also the possibility that a post-update or post-receive
hook will actually modify the ref *after* the push is "complete".
But that's like so crazy that I really don't think anyone has a
workflow that does that.  They might have such a hook that creates
a new ref however, or updates a totally unrelated ref (e.g. compile
the code and then update a "last-built" ref).

So in this particular case I have to agree with Daniel, its probably
OK to do what Cogito does and update the tracking branch after the
push was claimed to be successful by the remote.

-- 
Shawn.

  reply	other threads:[~2007-04-29  6:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-28 17:05 [PATCH 4/5] Add --remote option to send-pack Daniel Barkalow
2007-04-29  5:49 ` Junio C Hamano
2007-04-29  6:01   ` Daniel Barkalow
2007-04-29  6:10     ` Shawn O. Pearce [this message]
2007-04-29  6:28     ` Junio C Hamano
2007-05-03  4:04       ` Daniel Barkalow
2007-05-03  5:35         ` Junio C Hamano
2007-05-03  5:45           ` Daniel Barkalow
2007-05-03  6:13             ` Junio C Hamano
2007-05-05  5:21               ` Daniel Barkalow
2007-05-05  6:33                 ` Junio C Hamano
2007-05-05  6:52                   ` Daniel Barkalow
2007-05-05  7:54                     ` Junio C Hamano
2007-05-05 17:56                       ` Daniel Barkalow
2007-05-07 20:08                       ` Loeliger Jon-LOELIGER

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=20070429061006.GU5942@spearce.org \
    --to=spearce@spearce.org \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /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.