Re: My Itchlist

From: Junio C Hamano <junkio@cox.net>
Date: Aug 6, 2005, 19:04 UTC
Message-ID: <7voe8a6g5a.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0508060846050.12882@wgmdd8.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> I think that we need a method to do a push in reverse: If a central 
> repository has several branches, I might want to pull just those branches 
> where the local head is a strict parent of the remote side, and get 
> complains for the others. And maybe reference naming comes as a freebie 
> with that.

I can first run "git ls-remote" to discover what are available heads and tags, and choose to "git fetch" without actually merging nor touching my references if I did not want to. I could then attempt to "git resolve" offline, and if it results in a real merge, not fast forward, and if I am in a hurry and do not want to risk merging without thinking, I can just keep my head and defer the merging part. I think that is what you are getting at by "pull only when local is a strict parent of the remote".

It is really the matter of where the ancestry computation happens. You seem to think you would want to do it on the central server side, but I tend to think that should be done on the puller's side, like I outlined above. There are two reasons:

 (1) as you mentioned in a separate topic, the current
     upload-pack/fetch-pack protocol pair seems to put a
     nontrivial burden on the server side.  I'd prefer to have
     the client side do more work.

 (2) You are interested in that remote branch, so while you may
     not want to merge the upstream changes into the branch you
     have your local modifications right away, it is likely you
     eventually will.  Fetching the objects would not be a
     wasted traffic.

What Linus said makes a lot of sense to me. While the current "git fetch" user interface captures a commonly used pattern of fetching a single remote reference and optionally storing that remote reference as a local reference under refs/heads, it is cumbersome to use when you want to slurp objects needed for multiple remote references and not store the references themselves anywhere.