On Fri, 2 May 2014, David Kastrup wrote:

Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup <d...@gnu.org>
To: git@vger.kernel.org
Subject: Re: Pull is Mostly Evil

Marc Branchaud <marcn...@xiplink.com> writes:

To that end, I suggest that pull's default behaviour should be to do
*nothing*.  It should just print out a message to the effect that it
hasn't been configured, and that the user should run "git help pull"
for guidance.

Fetching is uncontentious, and I _think_ that fast-forwards are pretty
uncontentious as well.

so those people just need to use fetch instead of pull.

This seems fairly straightforward

fetch, get the data but don't integrate it

pull, get the data and ff along it if possible

pull with options, merge/rebase left/right based on options when ff is not possible.

Pull was created with one workflow in mind, Changing it to require explcitly specifying the option (in a config, with appropriate transition, handholding) is not completly unreasonable, and given the confusion this causes, may be very reasonable.

But saying that ff isn't always right, so make pull go away altogether (or "don't change anything because there isn't 100% agreement on the result" paralysis) doesn't seem right.

It's just when the merge-left/merge-right/rebase-left/rebase-right
decision kicks in that prescribing one git-pull behavior looks like a
recipe for trouble.

confusion at least. It's not fatal confusion, people have been using it for years after all.

David Lang
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to