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 wrote: > W. Trevor King wrote: > > 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". -- 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
