On Tue, 24 Oct 2006, Linus Torvalds wrote: > Yes. However, from a portability (to Windows) standpoint, shell is just > about the worst choice. > > Not that perl/python/etc really help - unless the _whole_ program is one > perl/python thing. Windows just doesn't like pipelines etc very much. > > So I'd like all the _common_ programs to be built-ins.. > And I would prefer the opposite because we're talking about git. As an information manager, it should be seen and not heard. Nobody is going to spend their time to become a git or CVS or perforce expert. As an individual primarily interested in development, I should not be required to learn command lines for dozens of different git-specific commands to do my job quickly and effectively. I would opt for a much more simpler approach and deal with shell scripting for many of these commands because I'm familiar with them and I can pipe any command with the options I already know and have used before to any other command. As a developer on Linux based systems, I should not need to deal with code in a revision control system that is longer and less traceable because the authors of that system decided they wanted to support Windows too. Moving away from the functionality that the shell provides is a mistake for a system such as git where it could be so advantageous because of the inherent nature of git as an information manager. This is the reason why I was a fan of git long ago and used it for my own needs before tons of unnecessary features and unneeded complexity was added on. David - 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