Re: branch.pu.forcefetch

From: Junio C Hamano <junkio@cox.net>
Date: Dec 29, 2006, 02:30 UTC
Message-ID: <7v8xgrsabr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1167355326.15189.34.camel@dv>

Pavel Roskin <proski@gnu.org> writes:

Show 5 quoted lines

>> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"?
>
> Yes, I'm talking about that line.  And I don't like that I have to use a
> magic token "refs/heads/pu" that doesn't correspond to a real file to
> make it possible to keep git up-to-date.

I think we misunderstood each other. That line is inconsistent with what your config has, which is the separate-remote layout, which I did not know you were using. In separate-remote layout, you don't have refs/heads/pu so if we do not do the patches you are agreeing to, you would want to have something like:

	[remote "origin"]
                fetch = +refs/heads/pu:refs/remotes/origin/pu
        	fetch = refs/heads/*:refs/remotes/origin/*

In other words, "path does not correspond to a real file" problem does not exist. If you tell git to track 'pu' at refs/remotes/origin/pu, it will use that path -- so that path has a corresponding real file.

> Unfortunately, updating the current branch fails because pu is not
> fast-forwarding.  Why fail if I'm not even on pu?

Your being not on 'pu' does not have anything to do with it. In fact, you do not even want to be _on_ any of your tracking branches. In the separate-remote layout, you cannot even be on remotes/origin/pu branch.

What you are seeing is fetch's safety feature that stops and notifies you the situation when the remote rewinds/rebases the branch you are tracking with tracking branches. We have had it turned on by default for a long time, and you have it turned on in your config because that is the default. If you do not want to use that feature (and for git.git, you certainly don't), just turn it off. When you know you do not want to use a feature, you do not have to.

Turning it off by default was not a wise thing to do in general for a long time, because rewound/rebased tip loses information, and we did not have reflog enabled by default. Your message raised this issue to attention of the list, and I suggested two patches out of it, both of which I think are sane things to do. If the list agrees, we can turn it off by default now.