On Friday, February 16, 2007 at 10:21:30 (-0500) Jeff King writes: >On Fri, Feb 16, 2007 at 09:13:22AM -0600, Bill Lear wrote: > >> % git pull ../peer_repo topic:topic >> [...] >> * refs/heads/topic: not updating to non-fast forward branch 'topic' of ../peer_repo >> [...] >> So, why does it say "not updating to non-fast forward branch", yet >> it does the merge and gets the changes anyway? > >Because your pull command really means "merge in the topic branch from >peer_repo, and while you're at it, store it in my local tracking branch >topic". Remember that pull is really a fetch+merge. But the fetch is >actually doing _two_ things: putting the fetched branch into FETCH_HEAD, >and putting it in into refs/heads/topic. The latter fails (because of a >non-fastforward), but pull actually uses the FETCH_HEAD results to >do the merge. > >Yes, this seems overly complex for what you're doing, but the reason for >FETCH_HEAD is to support pulls when you _don't_ have a tracking branch >at all (i.e., 'git pull ../peer_repo topic'). Ok, fair enough, but then I guess I'm back to my original question: how can I give a concrete demonstration to our developers that this is a bad thing? This is not 100% required, so if you are tired of answering my incessant questions, feel free to decline. I will be able to get our group to move forward, simply because we need to try to stay current, and there are lots of improvements in git besides this issue. 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