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