Re: Working with remotes; cloning remote references

[Marc Branchaud <marcnarc@xiplink.com>]

Michael J Gruber wrote:
> 
> "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