cron looks for
crontab files under a single directory, which would be unsuitable for per-user git repositories. I suppose you could replace
/usr/bin/crontab with code that, in addition to emulating
crontab(1), figures out who the user is, retrieves-or-creates their git-stored cron data, commits any changes, then makes that data available to
cron(8), either by calling the original
crontab(1) (due to the setgid bit), or being setgid itself (danger danger security warning!). System updates would also be complicated, as during an upgrade one would need to let the updated
/usr/bin/crontab be installed, then move that aside to install your git-enabled wrapper (and likewise for any patches that touch
Users who figured out where the original
crontab(1) is would be able to bypass the git stuff; to avoid that, your implementation would have to be setgid
crontab, which may open the door to arbitrary-overwrite-of-any-users-crontab-file security problems or in other words a great way to allow total system compromise (attacker writes to
root crontab file, they win!) should your code contain any security problems.
Also complicated is if the user figures out where their per-cron git repository is, then screws around with that; if that's a concern, those would need to be owned by some other user, and the custom
crontab(5) client would then talk to some daemon that does have rights to those repositories (e.g. how
sshd does privsep).
rcs may suffice if you merely need to track changes over time, and offers less rope to hang yourself with than