From: Philip Oakley Date: Thu, 01 May 2014 21:16:33 GMT Subject: Re: Pull is Evil Message-ID: In-Reply-To: Oops.. From: "Philip Oakley" > From: "Marc Branchaud" > Sent: Wednesday, April 30, 2014 8:45 PM > [...] >> I don't think we'll ever be able to create a One "Git Pull" To Rule >> Them All. >> At best we'll end up with something with enough knobs that it could >> be >> configured to work in most workflows (I think we're actually pretty >> close to >> that). But for new users that defeats the purpose. It means that >> "git pull" >> is really an advanced command, and beginners should avoid it until >> they >> understand enough of git to configure it properly. >> >> So rather than perpetuate the myth that one command can always (or >> even just >> usually) do the right thing, let's just retire the command. >> >> All that said, I don't object to any attempts at improving the >> command >> either. But I also don't see any kind of improvement that would lead >> me to >> start using "git pull" let alone recommending it to new users. >> >> M. >> >> [1] By "significant" I mean "enough to perpetually create new mailing >> list >> threads about changing 'git pull'". >> > [general reply to all, rather than to anyone in particular, using > Marc's summary] > > The point that there is no easy solution to an updated default pull > action that is right for everybody, straight out of the box, I think > is now fairly obvious, a summarised by Marc. I certainly avoid pull. > > My 'solution', if it could be called that, would be that at the point > of switch over, after a period of release note warning and then code > warning, that the plain 'git pull' would not even do the no-ff, but s/no-ff/--ff/g that is, only 'merge' if it's a fast forward. > would simply refuse to do anything unless the user had explicitly set > the [new] config variable(s) to a value of _their_ choice. The message > could give guidance based on their old setting(s) and the new options > as appropriate, i.e. if they have an old definitive setting then the > new setting may be an obvious one. > > During the warning period between the release cycles, we may have a > two step ramp up of the warning, where the first cycle allows users > who have read the release notes to choose their new setting and it's > auto detected from there on, then in the second cycle Git detects the > lack of a setting and gives a warning prompt (just like the Git 2.0 > warning), and finally the change over release makes a 'git pull' > without a config setting an error. > > I know that for some it's a phaff that appears to waste time (been > there, been that person), but it does allow the stragglers time to > pick up the hints and not be too surprised, which will include many > otherwise professional folks who just happen to have other priorities > [e.g. this message typed from a Win XP machine!]. > > The approach does have a solid heritage, and avoids anyone (on the > coding side) having to decide on an initial default, when it should be > a user choice. Though I do agree with Filipe that the '--no-ff merge' s/no-ff/--ff/ > would probably be the least worst for the new user and likely be a > suitable 'if you don't know use this one' suggestion. > > Philip > -- sorry for the finger-brain failures.