Not really. For one thing, the default version of git would quickly become outdated, and could potentially cause confusion with a user-installed version.
What Apple should really do is build a proper package management system. IMHO, that is a fundamental part of a modern operating system, especially one designed for use with F/OSS software.
The engineering effort required is too far outside their business focus. They've got a very basic one, but nothing in terms of what modern Linuxers are used to. They've blessed macports as their preferred one, which does a reasonable job.
As far as I've seen, apple will include the latest stable version of a tool per major upgrade (e.g. tiger, leopard, etc.). They'll keep it the same version until the next major one, without touching point releases. In terms of the principle of least surprises, it's actually the way I'd prefer.
The other post's advice for .bashrc is very good, it's what I do.
FWIW, macports is linked to from http://macosforge.org/ - which is open source stuff hosted by Apple and worked on by Apple engineers for the most part.
Apple actually had one of the old-time Debian guys, Klee Dienes, for a number of years, starting way back in 1997. I guess he wasn't successful in convincing them to do things properly.
It is possible to update the $PATH to grab from /usr/local/bin/* (user stuff land) before /usr/bin/* (system stuff land). If you're comfortable using command line to manage code, editing the ~/.bashrc shouldn't be too difficult to manage.
Yeah, obviously. But the point is that if the presupplied git quickly becomes out of date, what's the point in Apple shipping it and it taking up disk space? The Apple-supplied versions of other OSS packages (e.g. Ruby) don't exactly set a good precedent.
How often is there a new feature and not just a bugfix in git? Honest question as I don't use git.
And does git really use up that much space to be an issue? I imagine the problem is just conflicting binaries/libraries which can be fixed pretty easily in .bashrc...
But I bet many novice developers have been exposed to Ruby and Python (and SVN) because they shipped with OS X. Let's let newcomers use git without a custom install, and maybe it will lead to more widespread adoption.
You don't need the latest version of git for init, clone, add, commit, push, and pull to work.
Macports is better than nothing, but not by much. I admit it's a real blessing when it comes to something complex with a lot of dependencies - if it works, but a lot of the time it's more trouble than it's worth.
I've personally seen it delete the data during a postgres update, and it regularly runs roughshod over config files, etc. It screws up installs all the time, which can be a nasty surprise since it doesn't clean up after itself properly (this happened to me when it put a non-functioning ssh in my path, leading to a bit of panic when I suddenly needed it urgently). It can't clean up obsolete, well, anything without the "force" option, spewing spurious warnings all over the place .. except when it turns out they weren't spurious and you find out it deleted something critical. It's slow as hell to list what you do have installed. The maintainers are sloppy and non-working packages sit in the repos for weeks at a time (hello, Erlang).
Like I said, it's better than nothing, but I don't think anyone should use macports for anything that could conceivably store any data you care about. You will probably need to nuke /opt and re-build everything from scratch periodically, so make good and sure there's nothing in there that you care about. However, if you use it with caution and bear in mind the necessity of a periodic rebuild, it can be a big help.
Personally, I've had more trouble with macports than necessary. (Mostly because whenever I type 'port', I still get command not found.) It's much easier just to download the source, ./configure, make, and sudo make install.
Thats because macports installs itself to /opt/* which isn't in your $PATH. Easy to fix. But macports still causes more problems then its worth. So does fink for that matter.
What problems? Package dependency problems? The worse that I've had happen is having to deal with broken packages. The amount of times I haven't had to deal with figuring out dependencies makes it more then worthwhile, IMHO.
CVS is installed with Xcode as far as I can tell; Its in the iPhone SDK download (open the iPhone SDK.pkg up in Pacifist and look under DeveloperToolsCLI.pkg/usr/bin/).
Though I'm surprised OS X ships with SVN by default. FWIW, the version of SVN that ships is 1.4.4 (and it still hasn't been updated as of 10.5.6 or iPhone SDK for 2.2.1.
And Python.framework and Ruby.framework are installed to let you run other programs people write. Same reason you have Java, Tcl/Tk and all the ObjC/Cocoa frameworks. Having the frameworks != writing code.
I have a PPC powerbook and I'd much rather have a more recent Java then something like git which I can easily manage myself. But then the point is moot because if current rumors are true I probably won't be able to run 10.6 anyways.
What Apple should really do is build a proper package management system. IMHO, that is a fundamental part of a modern operating system, especially one designed for use with F/OSS software.