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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
