On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote: > 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. > 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). -- 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