Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > On 14-04-30 10:55 AM, Junio C Hamano wrote: >> Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > ... >>> Anyway, rather than ranting on I'll just suggest that there's not enough >>> commonality between the ways people use git to make it worthwhile trying to >>> teach pull how to deal with a significant number of them. I think the pull >>> command should be deprecated and quietly retired as a failed experiment. >> >> I almost agree with the first sentence in the last paragraph, and >> your bulletted list above supports it. >> >> I am not sure how the second sentence can follow as its consequence. >> >> If the conclusion were "maybe adding a 'git update' to match the >> expectation of those who build on top of the work of others (aka >> CVS/SVN style) more closely and teaching new users to use that >> instead of 'git pull' may be a good way forward", I can sort of >> understand (if I may not be able to immediately agree with, until I >> can regurgitate the ramifications of such a change) it. > > I think we would run into much the same problem with "git update" as we do > with "git pull".... 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". 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. > 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". Another way not to make any workflow assumption is to ask the user to tell us. -- 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