Re: Pull is Evil

[Marc Branchaud <marcnarc@xiplink.com>]

On 14-04-30 04:14 PM, Felipe Contreras wrote:
> Marc Branchaud wrote:
>> All that said, I don't object to any attempts at improving the command
>> either.  But I also don't see any kind of improvement that would lead
>> me to start using "git pull" let alone recommending it to new users.
> 
> What is wrong when `git pull` merges a fast-forward?

Nothing.  Everything.  It depends.

> The problems with `git pull` come when you can't do a fast-forward merge, right?

Some of them, maybe most of them.

But the reason "git pull" is broken is that any solution to the problems that
arise depend on the project's workflow.  That would be fine if there was a
workflow that suited some large majority of users, but there doesn't seem to
be one.

<aside>

I dug up the workflows question from the 2012 user survey[1], but it's less
revealing than one might like:

 19. What git workflow(s) is used by projects in which development you
participate?

single developer, only private repository (no interaction)		67%

centralized workflow (push to common repository)			69%

branched centralized (push to different branches in common repository)	50%

peer-to-peer workflow (all repositories roughly equal)			 9%

integration-manager workflow (maintainer pulls/applies patches to "blessed"
repository))	19%

dictator and lieutenants workflow (hierarchical workflow)		 5%

using collaborative code review tool, e.g. Gerrit			13%

other workflow, please explain						 2%

Total respondents	4352

Respondents who skipped this question	135

(IIRC, this was a "check all that apply" question.)

I don't think this lets us conclude anything about the popularity of merging
or rebasing, even though many respondents use a centralized workflow.  I use
a centralized workflow, and I will sometimes merge and sometimes rebase.  It
depends on the work I'm doing.

</aside>

		M.

[1] https://www.survs.com/results/QPESOB10/ME8UTHXM4M