Re: Should "pull --rebase" try to be a little cleverer?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 21, 2008, 16:21 UTC
Message-ID: <alpine.LSU.1.00.0801211619530.5731@racer.site>
In-Reply-To: <alpine.LFD.1.00.0801211054320.20753@xanadu.home>

Hi,

On Mon, 21 Jan 2008, Nicolas Pitre wrote:

Show 21 quoted lines

> On Mon, 21 Jan 2008, Johannes Schindelin wrote:
> 
> > last night an idea hit me: if I "git pull --rebase blabla master", it 
> > could be that "blabla" decided to rebase "master" already, and ATM 
> > this would lead to quite a few conflicts, since commits that were not 
> > mine were rewritten.
> 
> Indeed.
> 
> > However, if we already have refs/remotes/blabla/master, we could DWIM 
> > the --rebase call to
> > 
> > 	git rebase --onto FETCH_HEAD refs/remotes/blabla/master
> 
> I was believing this was already the case.  Mind you, I never verified 
> it.
> 
> I think the best is really to have the equivalent of:
> 
> 	git fetch blabla/master
> 	git rebase --onto blabla/master blabla/master@{1} HEAD

Not exactly... what would you do with this:

	git pull --rebase git://git.kernel.org/... master

Hm?

So I think that _only_ in the case that a remote ref is updated, _and_ that there is already one, can we do the DWIMery.

Ciao, Dscho