[RFC] pull/fetch rename

From: Thomas Rast <trast@student.ethz.ch>
To: <git@vger.kernel.org>
Cc: "Björn Steinbrink" <B.Steinbrink@gmx.de>
Subject: [RFC] pull/fetch rename
Date: Tue, 20 Oct 2009 19:47:45 +0200	[thread overview]
Message-ID: <200910201947.50423.trast@student.ethz.ch> (raw)

Hi all,

While everyone is busy in two other UI threads, I figured I might as
well toss up another (probably) controversial topic.

Especially on IRC, we see many people who are some combination of
misunderstanding, misusing or overusing git-pull.  I figure this is
the result of several factors, notably

a) pull/push are not symmetric,

b) guides/tutorials recommend pull for situations where they
   shouldn't,

c) people blindly fire commands at git.

While the latter two are probably hopeless, I find (a) rather
annoying.  It breaks everyone's intuition of git-pull when they first
see it.  (I know that BK has a pull that also merges, but I gather
from the manual [never used it] that you cannot do the equivalent of
git-fetch in BK.)

As you probably guessed by now, here is an idea for a very aggressive
transition plan to address (a) in four phases:

1. git-fetch gets options --merge/-m and --rebase that make it behave
   like (current) git-pull, but requiring explicit arguments.
   git-pull gets a new option --merge (-m) that only enforces presence
   of arguments.

2. git-pull refuses to do any work unless given either --merge or
   --rebase.  Deprecation warnings for this start at the same time as
   (1.).

3. git-pull becomes a synonym for git-fetch.

4. git-fetch gives deprecation warnings that point the user to
   git-pull instead.

(1.) is probably harmless and could be put into any particular
release.  (2.) obviously breaks everyone's favourite script and needs
to fall on a major release.  (3.) should be delayed significantly from
(2.) to allow time to expose such breakage, and similarly (4.) should
be delayed after (3.) (or just ignored, but in any case git-pull would
become the preferred spelling).

As you probably noticed, while 'git pull $remote $ref' only needs to
be changed to 'git pull --merge $remote $ref', this leaves a gap at
the current functionality of 'git pull' without arguments.  Björn laid
out a nice suggestion for a git-update in

  http://article.gmane.org/gmane.comp.version-control.git/130679

briefly summarised as: git-update would cover what 'git pull' (without
arguments) does right now.  However, it could also be restricted to
fast-forward updates by default (with per-branch configurability as
with current git-pull).

Comments?  Flames?  Improvements?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch