Subject: Re: What's cooking in git.git (topics)

From: Andreas Ericsson <[email-masked]>
Date: Wed, 28 Nov 2007 09:12:12 +0100

J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
>>
>>> If we really want a fetch+rebase script, OK, but call it something other 
>>> than pull.
>> Why?  pull = fetch + merge only because that was the originally envisioned 
>> way to pull remote changes into your local working tree.  However, I do 
>> not see why we should be married to pull being a fetch and a merge for 
>> eternity.
> 
> Two responses:
> 
> First, OK, if you want to say "pull" means "fetch something and then
> incorporate it somehow into your current branch", that doesn't bother me
> quite as much as saying that "pull" always means "fetch + merge", and
> that "rebase" is really just a special kind of merge.  It's clearly not
> a merge.
> 

I beg to differ. The end result is identical to a merge (assuming one
never does "git rebase skip", which otoh could be thought of as one way
of resolving a merge conflict). It's just history that doesn't turn out
the same. git has always been about content, so from that pov, a rebase
is exactly the same as a merge.

> Second: "fetch+rebase" will really have very different properties from
> "fetch+pull".

"fetch+merge", no?

>  It may be possible to make the former behave a little
> like the latter in some common cases, but it's going to complicated.

True. I don't think octopus rebase needs to be supported, for example.

-- 
Andreas Ericsson                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231