On 14-04-30 04:01 PM, Junio C Hamano wrote: > > Maybe I was unclear. > > I didn't mean "replace 'pull' with 'update' everywhere". I meant > "Introduce 'update' that lets integrate your history into that from > the remote, which is to integrate in a direction opposite from how > 'pull' does". That's what I understood. > Then the downstream people (i.e. by definition, most of us) would > use "git update" while integrators would use "git pull". There is > no workflow assumption if we do so. Isn't merge-or-rebase a workflow assumption? I don't think there's a good rule of thumb for that choice. Downstream-vs-Integrator doesn't seem like enough, nor does it seem as simple as "'git pull' should merge" and "'git update' should rebase" (or vice-versa). But maybe I'm wrong and there really is only one salient axis (be it that one or another). >> I don't think we'll ever be able to create a One "Git Pull" To Rule Them All. > > Yes, that is exactly why I mentioned "git update". I doubt that a new, additional command with different workflow assumptions will be any more successful. > Another way not to make any workflow assumption is to ask the user > to tell us. Yes. But I wouldn't expect a new user to be able to answer. 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