Re: Pull is Mostly Evil

From: Philip Oakley <philipoakley@iee.org>
Date: May 2, 2014, 22:34 UTC
Message-ID: <2F8B2EEED0594446A6FCF771BBEDFB56@PhilipOakley>
In-Reply-To: <5363ec734572a_70ef0f30cdc@nysa.notmuch>

From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Friday, May 02, 2014 8:05 PM

Show 24 quoted lines

> Philip Oakley wrote:
>> From: "David Kastrup" <dak@gnu.org>
>> > Marc Branchaud <marcnarc@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