> > 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. > That totally mirrors my experience. Unless you're teaching people totally new to SCM, they're likely to have experience of something else, and are likely to ask 'but how do I do xyz'. And sometimes the reply is rather embarrassing, as the new and powerful way involves 5x as many commands. That's where it gets the reputation of complexity (when actually it might be more correct to be a reputation of verbosity). I tend to actually avoid the commands (porcelain or plumbing) to begin with, and actually concentrate on the data structures (commits, blobs, index etc) - then how various people's repos look when you do particular commands. That way people tend to relax about the many commands as they can grok that there's probably lots of things you need to do bit by bit, but that aren't relevant to understand right now - this seems to help in abstracting away the complexity without sweeping it under the carpet. So I pretty much agree. Your set looks good, but I always do fetch and merge before pull, and also add rebase at the end. -- 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
