Marc Branchaud venit, vidit, dixit 10/20/08 18:50: > 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/*' If you want to fetch main's local branches also, use option "--add" here so that you don't override the default fetch refspec (forgot last time, sorry). > 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 because on ThingOne there is no such ref. > 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. I thought you wanted to avoid pulling directly from ThingOne to clone? If you pull directly you might as well set up the same remote config as on main: for the correct pull line you need to know the same info as for the correct remote config. git fetch git merge -s subtree remotes/ThingOne/master should do the trick. If that works you can set up things so that pulling from origin (pulling when you're in your integration branch) does that merge automatically, using branch.integrationbranch.remote=origin, branch.integrationbranch.merge=remotes/ThingOne/master (untested ;) ). To be clear: The idea here is that main decides which ThingOne branch to store in remotes/ThingOne/master and where to get it from; clones always pull that one. > 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. Well, it let's you decide: It tracks local branches by default, and using additional "git config" you can track remotes as well. You can also use the "--mirror" option to "git clone" or "git remote add", but that has other side effects. Cheers, Michael -- 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
