Re: [PATCH 4/5] Add --remote option to send-pack

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 29, 2007, 06:01 UTC
Message-ID: <Pine.LNX.4.64.0704290152410.28708@iabervon.org>
In-Reply-To: <7vtzuzg26l.fsf@assigned-by-dhcp.cox.net>

On Sat, 28 Apr 2007, Junio C Hamano wrote:

Show 18 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > With the --remote option, send-pack will look at the remote
> > configuration for the specified remote (which must match the
> > destination URL), and update the local tracking refs to match changes
> > it causes in the remote heads they track.
> >
> > The previous values of local tracking heads are ignored.
> 
> I didn't actually look at the code of this patch, as I am
> rejecting the initial round of [PATCH 2/5] this depends on, but
> this is one thing Cogito did that we don't, and I think it makes
> sort of sense.  We pretend as if we fetched back immediately
> after we pushed without giving anybody a chance to further
> update the refs we updated at the remote.  I generally do not
> like "pretend that we did something" when talking about reliable
> operations (and SCM _is_ all about reliable operation), and this
> behaviour is exactly it, but I think this one is excusable.

I'll redo the series soon, but I wanted to respond to the commentary on the general concept.

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.

	-Daniel
*This .sig left intentionally blank*