Re: Working with remotes; cloning remote references

> Thanks for the explicit instructions, but I think I'm still missing 
> something.  Here's exactly what I'm trying, just to make sure I'm not 
> doing something odd.
> 
> First I set up the remote in the main repo:
> 
> main/$ git remote add -f ThingOne git://thing/ThingOne.git
> main/$ git merge -s ours --no-commit ThingOne/master
> main/$ git read-tree --prefix=thing-one/ -u ThingOne/master
> main/$ git commit -m "Adding ThingOne"
> 
> Then I make a clone, fetch main's refs to ThingOne, and try to pull in 
> changes from ThingOne by using those refs:
> 
> $ git clone /path/to/main clone
> $ cd clone
> clone/$ git config remote.origin.fetch \
>          '+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'

> clone/$ git fetch
>  From /path/to/main/
>   * [new branch]      ThingOne/master -> ThingOne/master 
> 
> clone/$ git pull -s subtree git://thing/ThingOne.git ThingOne/master
> fatal: Couldn't find remote ref ThingOne/master

> Also:
> 
> Michael J Gruber wrote:
>>> 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.
> 
> I can appreciate that, but the approach leads to two consequences that I 
> suggest should be avoidable:
> 
> 1. A and B both have to set up the references to C themselves.  A can't 
> just piggyback on whatever B has already set up.  (This is the impetus 
> for my original message.)
> 
> 2. Suppose B is just a repository that's being shared between A and D -- 
> i.e. there's no B entity doing any work directly in B.  In this case if 
> A (or D) wants to change B's reference to C (say, to track a new branch 
> in C), they can't: B has to be changed directly, and nothing can be done 
> in a clone to accomplish this.
> 
> I admit I'm picking at nits here -- obviously someone is able to access 
> the B repo and do whatever needs doing.  I just feel that there are some 
> situations where you want the origin's remotes in your clone, and some 
> where you don't, and git should let you decide.