From: "David Kastrup" <>
Marc Branchaud <> 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.

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


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to