Junio C Hamano, Sun, May 06, 2007 10:00:25 +0200: > > > Is that possible? I'm fairly sure it used to be. > > I doubt we had that bug. If you allowed overwriting with +, it > would not have prevented a rewind (i.e. pull from Linus and then > pull from somebody who pulled from Linus earlier than you did). > If you didn't, then it would have failed the fetch. > Maybe we should not fail in the case the remote repo is older then local, but just to try to fast-forward local reference after a fetch and fail only if the fast-forward fails? Or introduce a new syntax for the strict reference succession and make fetch+fast-forward the default? Or the other way around, use something like "-from:to" to ignore fast-forwards failed because the "from" already has all the "to" has, which has precedents: make and its "-include", which ignores errors from non-existing files. Let us the local repo being in history younger then the remote: Whole history (anywhere) : A--B--C--D Local has (branch Tracking) : A--B Remote1 (where the Local is doing a fetch from): A--B--C Normal case, fetch will just update its reference in Local. It is now at C. Now suppose we have another remote Remote2, which is on B still. If Local does a fetch from that, usually the operation will fail. But if we do, for example, a fetch from Remote2 and store its reference locally somewhere and then try to merge Local with the stored reference, it shall result in nothing: everything's already merged: $ git branch * master Tracking $ git fetch Remote1 master:Tracking ...reference Tracking updated $ git fetch Remote2 master:tmp $ git checkout Tracking $ git merge tmp Already up-to-date. $ git branch -d tmp $ git checkout master - 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