Re: git guidance

Phillip Susi
2007-12-04T22:21:44Z

Al Boldi wrote:
> Judging an idea, based on a flawed implementation, doesn't prove that the
> idea itself is flawed.

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.

> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users. But what the git model is
> currently missing is a client manager. Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.

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?

> IOW, git currently only implements the server-side use-case, but fails to
> deliver on the client-side. By introducing a git-client manager that
> handles the transparency needs of a single user, it should be possible to
> clearly isolate update semantics for both the client and the server, each
> handling their specific use-case.

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.