From: "David Kastrup" <d...@gnu.org>
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.
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
--
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
