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