It isn't the implementation that is flawed, it is the idea. The entire
point of a change control system is that you explicitly define change
sets and add comments to the set. The filesystem was designed to allow
changes to be made willy-nilly. If your goal is to perform change
control only with filesystem semantics, then you have a non starter as
their goals are opposing. Requiring an explicit command command is
hardly burdensome, and otherwise, a git tree is perfectly transparent to
non git aware tools.
It isn't missing a client manager, it was explicitly designed to not
have one, at least not as a distinct entity from a server, because it
does not use a client/server architecture. This is very much by design,
not a work around.
What transparency are you requiring here? You can transparently read
your git tree with all non git aware tools, what other meaning of
transparency is there?
Any talk of client or server makes no sense since git does not use a
client/server model. If you wish to use a centralized repository, then
git can be set up to transparently push/pull to/from said repository if
you wish via hooks or cron jobs.
--
