Re: [RFC] pull/fetch rename

From: Wesley J. Landaker <wjl@icecavern.net>
Date: Oct 20, 2009, 19:59 UTC
Message-ID: <200910201359.30880.wjl@icecavern.net>
In-Reply-To: <200910201947.50423.trast@student.ethz.ch>

On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote:

Show 10 quoted lines

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

This may be minor, but also:

d) in mercurial, pull/push are symmetric, but fetch means pull+merge

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

I would love to see this change, not because I get confused about pull/fetch 
(it honestly only took a few days to get used to), but because having 
push/pull be symmetric just is so much more conceptually pure / easier 
explain to co-workers / separation between orthogonal operations / 
satisfying to my inner perfectionist / etc.

Show 13 quoted lines

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

Hmmm, maybe this would be better for easier transition; replace 2-4 above with:

2. git-pull learns --merge and gets a configuration option that allows 
turning auto-merging off (e.g. pull.merge = merge/yes (default), rebase, or 
no). This doesn't change any behavior by default, but allows individual 
users to essentially make pull == fetch, and is forward compatible with 
changes up to #4.

3. git-pull gives a deprecation warning if the configuration option is not 
set, but otherwise defaults to merge. To get rid of the warning, you can set 
it explicitly (one way or another).

4. The configuration option default changes to "no", and a helpful message 
is printed telling you that you can set the configuration option to merge to 
get the old behavior.

5. Drop deprecation messages. At this point, git fetch and git pull are 
identical, except git fetch never merges, regardless of the pull 
configuration setting.

This has a few nice properties:

  * There is lots and lots of warning; this transition could happen slowly.

  * Early on, it will be possible to make git pull have symmetric behavior 
by default, which is the desired endgame.

  * In the end, people who want "git pull" to always keep it's current 
behavior can do so by setting the proper configuration variable.

  * git fetch doesn't need to be deprecated (but could be).