On Mon, 23 Oct 2006, David Rientjes wrote: > > Some of the internal commands that have been coded in C are actually much > better handled by the shell in the first place. Others have answered this, but the thing is, it was a _wonderful_ way to prototype things, and to add obvious (and nice) early UI issues that made git much more usable. But no, things are not better handled in shell. Shell tends to make some things really _hard_ to do. A fair chunk of the rewrite was because core functionality made things easier. For example, the whole internal revision partsing library is really actually a lot more capable than we could easily expose as a simple pipeline: the original "git log" pipeline worked very well, and you can actually still use those kinds of pipelines for a lot of work, but at the same time, some things really just work better when you have "deeper" interfaces. For example, the revision parsing library not only makes "git log" trivial as C, it's also needed for an efficient "git annotate/blame/pickaxe" kind of thing. There are also things that are just ludicrously hard to do in shell-script, like exclusive and atomic file operations. We used perl and python for some things, but finding people who know them tends to be problematic, and python in particular was also a dependency problem too, so the fact that the default recursive merge was python wasn't wonderful. So I think the shell-scripts are great (and some of them quite likely will remain around for the forseeable future) for prototyping, but for core functionality they were not wonderful. They are sometimes good examples of how powerful a scripting language git can be, though. Scripting is still very important, even though a lot of the core stuff doesn't necessarily depend on being scripts itself. But error handling in scripting is very hard or inconvenient, especially in pipelines. So some things were actively problematic (ie "git-rev-list --all --objects | git-pack-objects") and moving it to use the internal library interface was simply technically the right thing to do. Others had real performance issues, eg the new merge in C is a lot faster. It was fast before, it's much faster still. Linus - 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