Re: Working with remotes; cloning remote references

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Oct 17, 2008, 19:50 UTC
Message-ID: <48F8ECA2.3040208@xiplink.com>
In-Reply-To: <48F8AA5E.6090908@drmicha.warpmail.net>

Michael J Gruber wrote:

Show 6 quoted lines

> 
> "pull -s strategy repo master" does a fetch followed by "merge -s
> strategy repomaster", where repomaster is the ref for master on repo.
> So, if you got that branch (repomaster=ThingOne/master) by cloning from
> main you can do the merge (subtree or other) on your clone, even without
> the remote repo config for ThingOne on clone.

I'm afraid I'm having trouble translating what you're saying into actual git commands (or are you proposing some new git functionality?). How would I get the ThingOne/master branch into the clone?

After some more thought I realized that the clone can just pull directly from the ThingOne repository:

clone/$ git pull -s subtree git://thing/ThingOne.git master

(I'm still getting used to git's ability to match commit IDs from anywhere -- it's magic! :) )

This goes a long way to where we want to be, in that we don't have to do our merging work in the original main repository.

It would be nice, though, if the clone were able to use the main repository's definition of the ThingOne remote. I can think of some plausible scenarios where a person could get confused about which repo/branch they're supposed to pull. It's easy to recover from that kind of mistake, but there'd be less chance of a mistake if one could tell git to "pull from X as defined in the origin repository".

And actually, git's remote functionality feels a bit crippled if clones can't make some use of the origin's remotes. Is there a reason for keeping remote definitions out of a clone?

		Marc