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

From: J. Bruce Fields <bfields@fieldses.org>
Date: Nov 27, 2007, 17:07 UTC
Message-ID: <20071127170749.GA19136@fieldses.org>
In-Reply-To: <Pine.LNX.4.64.0711271652070.27959@racer.site>

On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:

Show 11 quoted lines

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

Second: "fetch+rebase" will really have very different properties from
"fetch+pull".  It may be possible to make the former behave a little
like the latter in some common cases, but it's going to complicated.
And a lot of git-pull documentation is going to end up with clauses like
"...except if you're running pull in 'rebase' mode, in which case...".
Better to keep the two cases as separate operations with separate syntax
and man pages.  (But share where it makes sense--e.g. any syntax and
documentation of fetch part should be shared.)

--b.