Re: 'upstream' branches.

From: Alex Riesen <raa.lkml@gmail.com>
Date: May 6, 2007, 09:21 UTC
Message-ID: <20070506092129.GA2434@steel.home>
In-Reply-To: <7vy7k2e606.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano, Sun, May 06, 2007 10:00:25 +0200:

Show 8 quoted lines

> 
> > 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