Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > But I'm definitely biased because I think pull is pretty much broken: > > * New users are encouraged to use pull, but all too often the default > fetch-then-merge behaviour doesn't match their expectations and they end up > starting threads like this one on the mailing list. > > * If we change pull's default behaviour, we'll just be shifting the > mismatched expectations onto the other half of the new users who would be > happy with fetch-then-merge. > > * I'm not sure why new users are taught to use pull. I suspect it's because > it tries to hide the idea of local-vs-remote branches, and people writing git > tutorials don't want to overwhelm new users with what seems to be an internal > detail. But these notions are really fundamental to using git effectively, > and I think pull does everyone a disservice by trying to gloss them over. > > 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. -- 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