From: "Felipe Contreras" <>
Sent: Friday, May 02, 2014 8:05 PM
Philip Oakley wrote:
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.

So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only
does that.

That assumes that doing something is better than doing nothing, which is appropriate when the costs on either side are roughly similar. However in this case, as we have essentially all agreed, there have been some bad down sides. In that case a precautionary principle is more appropriate where doing nothing (that is git pull does nothing until user configured) is better.

While a shift to merging fast-forwards would reduce the cost difference, they have to be matched against the potential user confusions when comparing to all the old web miss-instructions, hence my shift away from trying to best guess a default, rather than simply suggest it as a suitable user choice.

Felipe Contreras
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