Re: pull.prompt or other way to slow/disable 'git pull'
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
Re: pull.prompt or other way to slow/disable 'git pull'
W. Trevor King wrote: 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? That's right. 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? I feel helpers are good when we are transitioning from an established Git behavior to a new one. Or when the operation is potentially dangerous. But a fast-forward merge is not dangerous, an in fact it's what the vast majority of people would want. Even more, I'm now feeling confident I will be able to put a proposal that allow a simple configuration to fulfill the need of these users without affecting anyone else negatively. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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:
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.
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.
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--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
W. Trevor King wrote: I've renamed this sub-thread (which started around $gmane/247835) to avoid potential confusion/dilution. Thanks. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff Sticking to my 'no-ff' topic branch example, this should have been: git merge --no-ff remote branch I want folks to use --ff-only when pulling their default upstream. That's proposed to be the default anyway, so they won't need it. 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? 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull.prompt or other way to slow/disable 'git pull'
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
signature.asc
Description: OpenPGP digital signature
