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

W. Trevor King wrote:

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

quoted

W. Trevor King wrote:

quoted

quoted

quoted

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.

Pulling some branch to a topic branch, or pulling a topic branch to
another branch?

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

`git pull` would do that by default.

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.

That makes sense, but other people would be OK with a ff merge.

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

I don't see why. It will alomst always be non-fast-fowrward, so you
should already be prepared for a merge (or rebase).

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

Nah. Most people would prefer a merge. And actually, quite many would
want jdoe/feature-y to be rebased on top of feature-x.

Either way it would be impossible for Git to figre out what you want to
do.

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).

I'd say they can be distinguished by what the user typed.
 

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.

Ineed, so why would you want so drastically different behavior?
 

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.

What I do in those cases is do both a merge and a rebase. If I resolved
the conflicts correctly in the rebase the result of the merge should be
exactly the same. It's not hard because rerere stores the conflict
resolutions of the rebase and the merge becomes much simpler. After I'm
certain the merge is correct, I remove the temporary rebased branch.

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

quoted

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.

-- 
Felipe Contreras