@Al ...
True ... should make another showing 4.x to keep up to date.
Space - yes, that is a concern but considering the original method of updating/upgrading actually doubles space usage and inode limits on shared hosting, where the git method doesn't. You have old code directory, plus the downloaded archive of code which must be un-compresses before taking the next step. One removes old code only after the upgrade has been tested and old code is no longer needed.
Using git the code stays in place as do plugins and git works only with core code changes, deletions, new files. No moving parts/pieces.
Plus, finishing the update/upgrade via command line takes web service out of the loop - just php talking to DB. No un-anticipated time outs.
Plus, downtime is kept to a minimum.
Plus, makes it much easier to get those point releases thus keeping core code up to date and most secure. That has always been a 'sore point' due to old method ... as the original poster in this thread said ... 'a pain ....'.
Plus, combine it with backup first as video shows we get 'two birds with one stone'.
One thing discovered ... cannot run cron job while in maintenance mode. And running cron job just before the git update/upgrade cleans up/makes tables smaller in some cases, etc.
With newer versions of Moodle there is a checks.php script which could be run just prior to the git acquisition of core code to make sure php version/extensions and DB version/config is OK.
Still, however, there is no check of plugin compatibility for destination version but that too could be accomplished via a moosh script run prior to the upgrade.
I truly do not see any downside to git!
Thanks for the quick critique and suggestion as well as your verification that the git method does indeed work! 
I'll send you a PM with a link you might want to check out after posting this!
'SoS', Ken
