On 2/16/07, Bill Lear <rael@xxxxxxxxxx> wrote:
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?
It no longer works with recent git, as of v1.4.4.1-37-gd25c26e. Now git-fetch exit with a non-zero status when fast-forward check fails, so the merge does not happen. Santi - 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