Re: Working with remotes; cloning remote references

[Marc Branchaud <marcnarc@xiplink.com>]

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

The config & fetch commands indeed add a 
.git/refs/remotes/ThingOne/master file to the clone, but I'm missing the 
magic words for how to use that ref.


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.

		Marc