On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > > > It would matter almost exactly zero.
> > > > 
> > > > Some folks have explicit merge policies, and deciding how much
> > > > that matters is probably best left up to the projects themselves
> > > > and not decided in Git code.
> > > 
> > > Let's make some fake numbers to see around how much this would matter.
> > 
> > The point isn't that this is a huge flaw, the point is that we should
> > be able to configure Git to match sane workflows.
> 
> The point is that we are tainting a discussion about how to improve the
> defaults for the vast majority of users

I've renamed this sub-thread (which started around $gmane/247835) to
avoid potential confusion/dilution.

> > The goal is to train them to do:
> > 
> > >   % git config --global pull.mode none
> > >   % git fetch
> > >   % git merge --no-ff

Sticking to my 'no-ff' topic branch example, this should have been:

  git merge --no-ff remote branch

I want folks to use --ff-only when pulling their default upstream.

> > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > that are already using the current 'git pull' incorrectly.
> 
> If you are going to train them to use a configuration, it should be:
> 
> % git config --global pull.ff false

I don't want all pulls to be --no-ff, only pulls from topic branches.
I think adding a prompt or making the integration a two-step
fetch/merge are both ways to jog a user into consciously evaluating
their actions.  I don't see how a changing the default single-step
pull strategy (whatever it is) will.  I also don't look forward to
explaining an adaptive strategy that tries to get my workflow right
without command-line ff options to folks on their first day using Git.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to