On Sun, Apr 06, 2008 at 06:11:12PM +0100, seventh guardian wrote: > I figured ;) Let me see if I can explain it better: > > remote master: the project git server, located remotely over the internet > local master: my laptop repository, made by cloning the project master repo > slave(s): my local machines, which clone the local master, instead of > the remote master (to save bandwidth) OK, I understand now. I think that is a reasonable terminology for your situation, but keep in mind that git doesn't really understand the concept of a "master". From the perspective of your slaves, there is only your "local master" as the remote "origin", and they can't tell any difference between that and the original "remote master". > So on the local master (my laptop) I did: > $ git-clone http://remote.master.address/foo/bar.git > > Because I had to do some local changes to the code (what I've called a > "local commit"), I did this on the local master: > $ git-commit -a > > Now I want a copy of the repository on another machine, "slave". So I do this: > $ git-clone ssh://local.master.address/path/to/repo > > Which gives the annoying error.. If I skipped the "local commit" > stuff, then the cloning would work perfectly. Hmm. This _should_ just work, but something funny is going on. For some reason the "local master" is telling us that his HEAD points to f7a51afd, but we don't actually get that object. But I'm not quite sure how we get into that situation; my guess is that there is something confusing going on at the remote master, since the http fetching code is not as strict and might fail to notice a missing object there. Is it possible for us to see the remote master so we can take a look? -Peff -- 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
