Re: Dangers of working on a tracking branch

["Santi Béjar" <sbejar@gmail.com>]

On 2/16/07, Bill Lear <rael@zopyra.com> 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