From: "David Kastrup" <redacted>

Marc Branchaud [off-list ref] writes:

quoted

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.

While the fast forward is /pretty/ uncontentious, it still maybe 
contentious for some. But more importantly (in my mind) is the fact that 
it (git pull) hasn't been configured, and pressing for _that_ to happen 
is the big benefit.

I'm more than happy that the fast-forward should be the recommended 'if 
you don't know, choose this' option, as you say, its pretty 
uncontentious and has easy mechanisms for backing out which are well 
illustrated across the internet.

It would still need a few cycles of ramping up the warnings to ease folk 
in gently. One has to beware of the issues at both ends of the Kruger 
Dunning curve. This thread discussion in some ways has suffered from the 
inverse K-D effect.

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.

-- 
David Kastrup

--
Philip