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

From: Andreas Ericsson <ae@op5.se>
Date: Nov 28, 2007, 08:12 UTC
Message-ID: <474D22DC.1060408@op5.se>
In-Reply-To: <20071127170749.GA19136@fieldses.org>

J. Bruce Fields wrote:

Show 20 quoted lines

> 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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231