Re: pull.prompt or other way to slow/disable 'git pull'

["W. Trevor King" <wking@tremily.us>]

[-- Attachment #1: Type: text/plain, Size: 6065 bytes --]

On Sat, May 03, 2014 at 04:50:52AM -0500, Felipe Contreras wrote:
> Either way it would be impossible for Git to figre out what you want
> to do.

That's my point.  The details of my particular workflow are
unimportant.

> Anyway I don't see how is this possibly relevant to the topic at
> hand.

I'm trying to motivate a way to slow/disable 'git pull', which I see
as orthogonal to your push to change the default configuration.  I
thought describing my workflow in more detail would help clarify why…

> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > > > 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.

… this global pull.ff config was not a solution.

> > > Either way, since I think these two are different modes:
> > > 
> > >   1) git pull
> > >   2) git pull origin topic
> > > 
> > > Maybe it would actually make sense to have a configuration specific to
> > > 2): pull.topicmode.
> > 
> > I think it makes more sense to just use merge/rebase explicitly,
> 
> Fine, if you want the user to be explicit, he can be explicit with
> `git pull --no-ff origin topic`. Problem solved.

That's certainly explicit, but some folks are in the habit of just
running 'git pull' (regardless of which branch they happen to be on)
without thinking “Where am I, what am I integrating, and how should I
integrate it?”.  As I claimed earlier:

On Thu, May 01, 2014 at 06:10:04PM -0700, W. Trevor King wrote [1]:
> Folks who are setting any ff options don't need any of these
> training wheels.  My proposed --prompt behavior is for folks who
> think “I often run this command without thinking it through all the
> way.  I'm also not used to reading Git's output and using 'reset
> --hard' with the reflog to reverse changes.  Instead of trusting me
> to only say what I mean or leaving me to recover from mistakes,
> please tell me what's about to change and let me opt out if I've
> changed my mind.”

In the messages following that, you seemed to agree that such folks
existed [2], and suggested I use pull.mode=fetch-only [3] or
pull.ff=false [4] or pull.topicargs='--merge --no-ff' [5].  Now we
agree (I think?  Based on your “it would be impossible for Git…”
quoted above) that you can have a sane workflow for which no
pull-strategy default will always do the right thing.  We just
disagree (I think) on what to do about it.  I'm suggesting
pull.prompt, pull.mode=none, or some other way to slow/disable 'git
pull' while folks retrain themselves.  You're suggesting (I think?
Based on your 'git pull --no-ff origin topic' quoted above) that folks
just skip right to remembering which ff options to use in which
situations.  Do you feel folks won't need a way to slow/disable 'git
pull' while they build the ff options and their project's recommended
workflow into their own practice?  Or do you agree that they will need
some kind of helper for the transition, and just feel that git.prompt
is the wrong helper?

Cheers,
Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/247917
[2]: http://article.gmane.org/gmane.comp.version-control.git/247919
     On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > Folks who are setting any ff options don't need any of these
     > > training wheels.
     >
     > Indeed.
[3]: http://article.gmane.org/gmane.comp.version-control.git/247957
     On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
     > > > W. Trevor King wrote:
     > > > > But once such folks are identified, you just have to
     > > > > convince them (once) to set the pull.prompt config.
     > > > > That's a lot easier than convincing them (for every pull)
     > > > > to set the appropriate ff flag.
     > > >
     > > > It wouldn't matter if by the default non-fast-forward
     > > > merges are rejected.
     > >
     > > It would matter if you didn't want them making
     > > non-fast-forward merges (e.g. for explicitly-merged topic
     > > branches).
     >
     > It would matter almost exactly zero. And just as they can do
     > pull.promot = true, they can do pull.mode = fetch-only.
[4]: http://article.gmane.org/gmane.comp.version-control.git/247986
     On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > Saying “that's unlikely to happen” doesn't solve the problem
     > > that some newcomers have trouble matching their project's
     > > desired workflow.
     >
     > % git config --global pull.ff false
     >
     > Done.
[5]: http://article.gmane.org/gmane.comp.version-control.git/247998
     On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > I don't want all pulls to be --no-ff, only pulls from topic
     > > branches.
     >
     > Pulling some branch to a topic branch, or pulling a topic
     > branch to another branch?
     >
     > Either way, since I think these two are different modes:
     >
     >   1) git pull
     >   2) git pull origin topic
     >
     > Maybe it would actually make sense to have a configuration
     > specific to 2): pull.topicmode.
     >
     > This way they could do "pull.topicmode = merge-no-ff". Or maybe
     > we need arguments: "pull.topicargs = --merge --no-ff".

-- 
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]