After poking this hornet's nest I pretty much have stood back and not participated in the ensuing discussions. But having unleashed the hornets I feel I should at least say something, if only to assure people that I'm not ignoring their plight. There have been various proposals to modify git-pull's defaults, and/or extend it with new configuration settings, and/or add a new command. As I don't use "git pull" I feel I'm not in any position to comment about the particulars of these proposals. However I remain skeptical that these proposals, in any form, will really be all that helpful to new users. That's because in order to know whether or not "git pull" (or "git update") does what the user wants, the user has to understand the intricacies of both their own workflow and how git can work within that workflow. By the time a user gains that understanding, she is no longer a new user. Still, I do think the pull command is useful. In particular I think that a project can benefit greatly by tailoring pull's behaviour to match its workflow, and that a project's participants can be told how to configure git so that pull works properly for that project. Maybe even such configuration -- a "workflow blueprint" if you will -- can be tracked inside the project itself, so that a fresh project clone can automatically have "git pull" properly configured. To me this seems like a fabulous feature for git. But for now I go back to what I said before: Give "git pull" enough knobs to let people tailor it to their individual projects' needs. But also disable "git pull" by default, because nobody should run it until they've considered how they want it to work. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html