Re: Working with remotes; cloning remote references

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Oct 20, 2008, 16:50 UTC
Message-ID: <48FCB6B8.6090708@xiplink.com>
In-Reply-To: <48FC8624.9090807@fastmail.fm>

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:

Show 10 quoted lines

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