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...
Comments
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.
The engineering effort required is too far outside their business focus.
Then they should stop claiming that OSX is suitable for use as a server OS.
Muahahaha, that's just an inside joke :-)
Seriously, apple only cares enough about servers/etc to have a complete solution for their other markets, such as small business & education.
Why not just adopt .deb and apt?
Same response to macports below: Not-Invented-Here syndrome.
I suspect they've got the same problem others do: a case of NIH, without the resources to invent it themselves.
Ugh.
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.
They should strip out their custom builds and have macports pre-installed.
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...