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

On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:

The latter.  Here's a more detailed list:

1. HEAD: an integration branch (master, maint, …)
   target: @{upstream}, branch.*.pushremote, and other mirrors
   my preferred integration mode: ff-only merge the target

2. HEAD: an integration branch
   target: a *different* branch (e.g. maint or feature-x, but not
     origin/master or jdoe/master, if HEAD is master)
   my preferred integration mode: no-ff merge the target into HEAD.

3. HEAD: a topic branch (e.g. feature-x)
   target: a collaborating topic branch (jdoe/feature-x)
   my preferred integration mode: ff-only merge the target

4. HEAD: a topic branch (e.g. feature-x)
   target: a related topic branch (e.g. jdoe/feature-y) or integration
     branch updates used by my feature-x
   my preferred integration mode: rebase feature-x onto the target

Cases 1 and 2 can usually be distinguished by comparing the checked-out branch with the branch portion of the remote-tracking reference), but for folks developing in master, jdoe/master may be a feature branch (case 2) not a mirror of the maintenance branch (case 1).

Cases 1 and 3 are the same idea, with any feature branch running long enough to get collaborators being indistinguishable from an integration branch except that the latter will eventually be merged (or dropped) and deleted.

In the event of non-trivial merge conflicts in case 2, I sometimes rebase the target onto HEAD and no-ff merge the resulting target'. On the other hand, sometimes rebasing is not an option. For example, if I want to merge the target into both master and maint, but master contains a conflicting commit A:

  -o---o---A---o---B  master
   |\
   | o---o---C  maint
    \
     o---D  target

Rebasing would drag A into maint at F:

  -o---o---A---o---B---E  master
    \       \         /
     \       o---D'---  target'
      \           \
       o---o---C---F  maint

And I don't want both the pre- and post-rebase versions in my history at G:

  -o---o---A---o---B---E---G  master
   |\       \         /   /
   | \       o---D'---   /  target'
   |  \                 /
   |   o---o---C---F----  maint
    \             /
     o---D--------  target

So I'd just deal with a complicated merge at E:

  -o---o---A---o---B---E---G  master
   |\                 /   /
   | o---D------------   /  target
    \           \       /
     o---o---C---F------  maint

Case 4 has similar caveats, since you don't want to rebase feature-x on top of jdoe/feature-y if there are already other branches based on the current feature-x that can't (or won't) be rebased.

I think it makes more sense to just use merge/rebase explicitly, and not try and bundle all of this complication into something that *also* fetches. Unfortunately, there's currently no finger-breaker to help compulsive pull users break the habit or keep novices from starting. Adding more elaborate handling to pull just pushes back the point where you reach something that is pretty much impossible to resolve automatically (like my case 2 caveat). When that happens, it would be nice to have a workflow independent way to calm the pull-happy user (e.g. pull.mode=none, or pull.prompt=true) while they learn to explicitly use fetch/{merge|rebase} or more careful pulls.

Cheers, Trevor