On Thursday, February 1, 2007 at 09:24:34 (-0600) Bill Lear writes: >My fetch from a peer's public repo seems to be failing: > >% git --bare fetch git://source/public/project topic:topic >remote: Generating pack... >remote: Done counting 48 objects. >remote: Result has 34 objects. >remote: Deltifying 34 objects. >remote: 100% (34/34) done >remote: Total 34, written 34 (delta 22), reused 24 (delta 12) >Unpacking 34 objects > 100% (34/34) done >* refs/heads/topic: not updating to non-fast forward branch 'topic' of git://source/public/project > old...new: 1c332f5...f3b18ff > >I assume that is because his public repo does not contain changes I >have pushed into my public repo. So, I asked him to pull from >my public repo into his. He did, and said that git blathered that >there were 12 changed files, etc. Ok, I think I have discovered the cause... Sorry for wasting time. My pal did a git pull from my public repo's topic branch into his master branch by mistake. My fetch of his topic branch of course failed, as he did not update it. You know, some training wheels for git might be nice... Such as a git config variable: [newbies] please.god.save.me.if.I.try.to.merge = true Which would cause git-pull, git-fetch, git-merge (whatever) to prompt you: Hey Nimrod, you're about to MERGE something from one branch to another --- are you sure you really want to do this? (y/n) I myself have shot several repos in the head by doing this by mistake. Once this is done, and you pull it into your private repos, the infection spreads, and you have to go back to each and repair them... We'll get this right soon... Bill - 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