Re: [PATCH 0/3] Reject non-ff pulls by default
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Sep 9, 2013, 23:02 UTC
- Message-ID
- <CAMP44s0y-cpEWuPTQSwC-Hyp-RNcwdyDRTbAsUewH5bAPPMXuQ@mail.gmail.com>
- In-Reply-To
- <20130909202435.GJ2582@serenity.lan>
On Mon, Sep 9, 2013 at 3:24 PM, John Keeping <john@keeping.me.uk> wrote:
Show 31 quoted lines
> On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote: >> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote: >> >> > You are in favor of an _option_ to allow people to forbid a pull in >> > a non-ff situation, and I think other people are also in >> > agreement. So perhaps: >> > >> > - drop jc/pull-training-wheel and revert its merge from 'next'; >> > >> > - update Felipe's series with a bit of tweak to make it less >> > impactful by demoting error into warning and advice. >> > >> > would be a good way forward? >> >> I think that would address the concern I raised, because it does not >> create a roadblock to new users accomplishing their task. They can >> ignore the warning, or choose "merge" as the default to shut up the >> warning (and it is easy to choose that if you are confused, because it >> is what git is doing by default alongside the warning). > > I think we need to make sure that we give instructions for how to go > back if the default hasn't done what you wanted. Something like this: > > Your pull did not fast-forward, so Git has merged '$upstream' into > your branch, which may not be correct for your project. If you > would rather rebase your changes, run > > git rebase > > See "pull.mode" in git-config(1) to suppress this message in the > future.
And you propose to show that every single time the user does a 'git pull'' that results in a non-fast-forward merge? Isn't that what 'git pull --help' is for?
-- Felipe Contreras