Re: git guidance

From: Phillip Susi <psusi@cfl.rr.com>
Date: Dec 4, 2007, 22:21 UTC
Message-ID: <4755D2E8.5050402@cfl.rr.com>
In-Reply-To: <200712010950.15628.a1426z@gawab.com>

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.

Show 5 quoted lines

> 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?

Show 5 quoted lines

> 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.