Johannes Schindelin <[EMAIL PROTECTED]> writes:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
