On Tue, 14 Nov 2006, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxx> writes: > > > On Tue, 14 Nov 2006, Jakub Narebski wrote: > > > >> The git interface refactoring should be I think the cause for git 2.0.0 > >> release... > > > > Good idea indeed. > > We need to avoid user confusion, so making a command that used > to do one thing to suddenly do something completely different is > a no-no. However, I do not think it needs to wait for 2.0.0. > We can start with a separate namespace (or even a separate > "Improved git UI project") and introduce the "improved UI set" > in 1.5.0 timeframe. Dunno. I feel this is a bit overboard. Actually the naming problem is rather localized to one command, namely git-pull. In my opinion going with yet another namespace which would rather add to the confusion not clear it. The best way to avoid user confusion is to remove the source of the confusion not let it live. In other words I think we should _fix_ git-pull instead of replacing it. People are already confused about it so simply fixing this command will have a net confusion reduction. Yet we're not talking about "suddenly doing something completely different" either. If git-pull doesn't merge automatically anymore it is easy to tell people to use git-merge after a pull. "You pull the remote changes with 'git-pull upstream,, then you can merge them in your current branch with 'git-merge upstream'." Isn't it much simpler to understand (and to teach) that way? Also I don't think using git-upload and git-download is much better. This adds yet more commands that do almost the same as existing ones but with a different name which is yet not necessarily fully adequate. I for example would think that "download" is more like git-clone than git-fetch or git-pull. Let's face it: HG got it right with pull and push and newbies have much less difficulty grokking it. We screwed it by not using the most intuitive semantic of a pull and locking the word "pull" away is not the better solution given all considerations. Why just not admit it and avoid being different than HG just for the sake of it? Nicolas - 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