On Wed, 25 Oct 2006, Jeff King wrote: > 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? > No, my criticism is against the added complexity which makes the modification of git increasingly difficult with every new release. It's a pretty limited use case of the entire package, I'm sure, but one of the major advantages that I saw in git early on was the ability to tailor it to your own personal needs very easily with some simple shell knowledge and enough C that was required at the time. > Some C->shell conversions may have made the code "longer and less > traceable." However, many of those conversions caused the code to be > shorter (because communication between C functions is simpler than going > over pipes, and because anything involving a data structure more complex > than a string is difficult in the shell) and more robust (fewer > opportunities for quoting/parsing errors, and none of the shell gotchas > like missing the error code in "foo | bar"). > You're ignoring the advantageous nature of the shell with regard to git. The shell is so much better prepared to deal with information managers by nature than the C programming language. It's not a matter of shorter code, per se, it's about the developer's ability to make small changes to the operation of the information manager on demand to tailor to his or her _current_ needs. For any experienced shell programmer it is so much easier to go in and change an option or pipe to a different command or comment out a simple shell command in a .sh file than editing the C code. And sometimes it's necessary to have several different variations of that command which is very easy with slightly renamed .sh files instead of adding on more and more flags to commands that have become so complex at this point that it's difficult to know the basics of how to manage a project. This all became very obvious when the tutorials came out on "how to use git in 20 commands or less" effectively. These tutorials shouldn't need to exist with an information manager that started as a quick, efficient, and _simple_ project. You're treating git development in the same light as you treat Linux development; let's be honest and say that 99% of the necessary git functionality was there almost a year ago and ever since nothing of absolute necessity has been added that serious developers care about in a revision control system. Look at LKML, nobody is waiting on these new releases and upgrading to them when they're announced. And this is the community that git has _targeted_. Most other projects don't care about the syntactics of sign-off lines and acked-by lines and format-patch like the git community does. > Do you have any specific reason to believe that the git code is of worse > quality now than it was before? > Absolutely. I think I've actually documented that fairly well. Back in the day git was a very concise, well-written package. Today, a tour through the source code for the latest release leaves a lot to be desired for any serious C programmer. > Is there something you used to do with git that you no longer can? Is > there a reason you can't ignore the newer commands? > Functionality wise, no. But in terms of being able to _customize_ my version of git depending on how I want to use it, I've lost hope on the whole idea. It's a shame too because it appears as though the original vision was one of efficiency and simplicity. I would say that git-1.2.4 is my package of preference with some slight tweaking in the branching department. I really do miss the old git. 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