From: Santi Béjar Date: Fri, 16 Feb 2007 16:10:57 GMT Subject: Re: Dangers of working on a tracking branch Message-ID: <8aa486160702160810i3d92ba6fy390674dfcc9c584@mail.gmail.com> In-Reply-To: <17877.52593.509791.685008@lisa.zopyra.com> On 2/16/07, Bill Lear 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