Re: Working with remotes; cloning remote references

[Michael J Gruber <michaeljgruber+gmane@fastmail.fm>]

Marc Branchaud venit, vidit, dixit 17.10.2008 21:50:
> 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?

Sorry for being cryptic. What I meant was: The clones don't need the
full remote config of main in order to get main's remote branches for
the ThingOne remote. Say, main stores the remote tracking branches for
ThingOne in "refs/remotes/ThingOne", using an appropriate remote config.
Then a clone could use the refspec
"refs/remotes/ThingOne/*:refs/remotes/ThingOne/*" (when fetching from
main) in order to fetch those branches, without having a remote config
for ThingOne on the clone. Concretely:

git config remote.main.fetch
'+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'

on a clone which has a remote config "main" for the main repo.

> 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 thought that's what you were trying to avoid...

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

... but this explains everything ;)

> 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".

I think the approach I outlined above could solve this: main prepares
everything to be pulled under refs/remotes/ThingOne, and clones (i.e.
clone users) are told to fetch with a refspec like above. This way they
get a copy of main's remote tracking branches for ThingOne. (Maybe you
use one branch only, then the refspec is even simpler.)

> 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?

Say A and B are working on a project C. Then, typically, A is interested
in B's work on C, i.e. some of B's local branches, but not on B's remote
 tracking branches: A tracks a "central" C already, just like B does,
and remote tracking branches don't carry any "value adding" by the
cloner, they're just a local unmodified copy of the remote.

But you can always add a refspec like above.

Michael