You can publish a Git repository on any old web server, without needing a special git daemon, using a command called ‘git-update-server-info’. This would be useful if you wanted to publish some code but lacked the ability to offer any old user an ssh login, perhaps because you are using a hosting service instead of running your own server. Here are a couple of how-to guides:
git-server for the poor: git-update-server-info, rsync, and remote repository
How to publish a Git repository
SourceForge FAQ for Git development
It is also possible to create a patch file with git which you can send via email. I am thinking about setting up an auto-build-verify system that checks a dedicated email inbox, downloads patch files, builds them on a temporary branch, runs a validation suite, and either pushes the changes up to another repository or sends back an email describing the errors that occurred.
We were working toward a system like that just before I left Real Software, using Buildbot. It was a big improvement over the ad-hoc practices we’d always used before, but it was still a reactive notifier rather than an active filter. You checked in code first, then the buildbot would run its tests to see whether you broke anything. It was much better than hearing about it from one’s irritated colleagues a day or two later, but still too fragile.
It was much harder to break the build at Microsoft, where no change could be committed until it included a new test suite and had been shown to pass every existing test. This was unfortunately a completely manual process and thus extremely time-consuming, but it did create an unusual degree of confidence in the checkins, when they finally did happen.
Grunt work is a waste of human time: that’s what robots are for. I want to send my code off to the build system whenever I think it’s ready, let it do the repetitive validation, and then either pass the code on to the development trunk or let me know what went wrong. If I screw up, I’ll have a chance to fix it before I waste anyone else’s time dealing with the problem, and I’ll know that code I pull from the trunk will always work as far as the test suite is concerned.
