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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 3, 2014, 09:50 UTC
Message-ID: <5364bbfc8c0a0_ac68dd308ce@nysa.notmuch>
In-Reply-To: <20140503000530.GP28634@odin.tremily.us>

W. Trevor King wrote:

Show 19 quoted lines

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

Show 5 quoted lines

> 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?

Show 42 quoted lines

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

Show 9 quoted lines

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