Re: git guidance

[Phillip Susi <psusi@cfl.rr.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.

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