On Wed, Jul 16, 2008 at 01:12:53PM -0700, Junio C Hamano wrote: > If you are advocating that mode of operation to be easy in git, you should > think again. That pull (be it with or without --rebase) can conflict and > you would need to resolve it, and then your "stash pop" can conflict > again. You can have your own "git avery-up" alias which is your "svn up" > equivalent, but if you train users with that first, the users have to > learn how to cope with conflicts in individual steps anyway. > > Making these three into a single alias is not an improvement either. If > you are not ready to incorporate other's changes to your history, why are > you pulling? Being distributed gives the power of working independently > and at your own pace. You should train your brain to think about the > workflow first. "You should stash before pull" is _not_ a good advice. > "Do not pull when you are not ready" is. What I've found is that some people will take that advice, and other people won't. Saying that you are thinking about things the wrong way doesn't really help for people who have been so ingrained into an old way of doing things. Indeed, it can end up sounding very elistist. So from a pedagogical perspective, what I would probably do is show them how to replicate svn-up, and explain to them how this script works: #!/bin/sh # git-up if git diff --quiet && git diff --quiet --cached ; then git pull $* else git stash ; git pull $*; git stash pop fi And then tell them that if this put this into their path, then "git up" will work the same way as "svn up" --- but that git has a better way of doing things, and why it is so. And then what I would tell them is that no really, merges are really easy with git, and that even if they were to rely on the "git up" alias as a crutch, that over time they would find that there are much more natural, easy, and powerful ways of doing things. In general, I find that people are more willing to listen to "we have a more powerful way of doing things", if you can first give them the equivalent of the "dumb and stupid" way that they are used to doing things so they can switch to the new tool right away without too much of a steep learning curve; they will then switch to the more advanced/powerful workflows at their own pace. Other people may have other pedgogical techniques, but I find mine to work fairly well. Regards, - Ted -- 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
