Jeff King <peff@xxxxxxxx> writes: > On Tue, Oct 24, 2006 at 01:12:52PM -0700, David Rientjes wrote: > >> 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. > > I don't understand how converting shell scripts to C has any impact > whatsoever on the usage of git. The plumbing shell scripts didn't go > away; you can still call them and they behave identically. > > Is there some specific change in functionality that you're lamenting? That's also I wondered, but I also can understand where David is coming from, and I agree with him to a certain degree. When I learned git, I learned a lot from trying to piece my own plumbing together, since there weren't much Porcelain to speak of back then. Then we had many usability enhancements before the 1.0 release to add Porcelainish done as shell scripts. This had two positive effects, aside from adding usability. Interested people had more shell scripts to learn from. The scripts were easy to adjust to feature requests from the list, and as we learned from user experience based on these scripts it was definitely quicker to codify the best current practice workflow in them than if they were written in C. It would have taken us a lot more effort to add "git commit -o paths" vs "git commit -i paths" if it were already converted to C, for example. This continued and our Porcelainish scripts matured quickly. Then 1.3 series started to move some of the mature ones into C. As many people already have pointed out, being written in C and not doing pipe() has two advantages (better portability to platforms with awkward pipe support and one less process usually mean better performance). git-log family with path limiting had a real boost in performance because the path limiting can be done in the revision traversal side not diff-tree that used to be on the downstream side of the pipe. So this in overall was a right thing to do. One thing we lost during the process, however, is a ready access to the pool of "sample scripts" when people would want to scratch their own itches. Linus's original tutorial talked about "this pattern of pipe is so useful that we have a three liner shell script wrapper that is called git-foo", and interested people can easily look at how the plumbing commands fit together. The plumbing is still there, and I and people who already know git would still script around git-rev-list when we need to (by the way, scripting around git-log is a wrong thing to do -- it is for human consumption and scripting should be done with plumbing). But when we rewrote mature ones in C (and I keep stressing "mature" because another thing I agree with David is that shell is definitely easier to futz with), we did not leave the older shell implementation around as reference. People coming to git after 1.3 series certainly do have harder time to learn how plumbing would fit together than when git old-timers learned it, if that is the area they are interested in, as opposed to just using git as a revision tracking system. We could probably do two things to address this issue: - Create examples/ hierarchy in the source tree to house these historical implementations as a reference material, or an entirely different branch or repository to house them. - Learn the itches David and other people have, that the current git Porcelain-ish does not scratch well, and enrich Documentation/technical with real-world working scripts built around plumbing. - 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