On Fri, 2 May 2014, David Kastrup wrote:
Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup <dak@xxxxxxx>
To: git@xxxxxxxxxxxxxxx
Subject: Re: Pull is Mostly Evil
Marc Branchaud <marcnarc@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html