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 andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
