Re: Pull is Mostly Evil

From: Marc Branchaud <marcnarc@xiplink.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: Re: Pull is Mostly Evil
Date: Fri, 09 May 2014 15:49:25 -0400	[thread overview]
Message-ID: <536D3145.7080305@xiplink.com> (raw)
In-Reply-To: <5363BB9F.40102@xiplink.com>

After poking this hornet's nest I pretty much have stood back and not
participated in the ensuing discussions.  But having unleashed the hornets I
feel I should at least say something, if only to assure people that I'm not
ignoring their plight.

There have been various proposals to modify git-pull's defaults, and/or
extend it with new configuration settings, and/or add a new command.  As I
don't use "git pull" I feel I'm not in any position to comment about the
particulars of these proposals.

However I remain skeptical that these proposals, in any form, will really be
all that helpful to new users.  That's because in order to know whether or
not "git pull" (or "git update") does what the user wants, the user has to
understand the intricacies of both their own workflow and how git can work
within that workflow.  By the time a user gains that understanding, she is no
longer a new user.

Still, I do think the pull command is useful.  In particular I think that a
project can benefit greatly by tailoring pull's behaviour to match its
workflow, and that a project's participants can be told how to configure git
so that pull works properly for that project.  Maybe even such configuration
-- a "workflow blueprint" if you will -- can be tracked inside the project
itself, so that a fresh project clone can automatically have "git pull"
properly configured.   To me this seems like a fabulous feature for git.

But for now I go back to what I said before:  Give "git pull" enough knobs to
let people tailor it to their individual projects' needs.  But also disable
"git pull" by default, because nobody should run it until they've considered
how they want it to work.

		M.