Message-ID: <4755D2E8.5050402@cfl.rr.com>
Date: Tue, 04 Dec 2007 17:21:28 -0500
From: Phillip Susi <psusi@cfl.rr.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Al Boldi <a1426z@gawab.com>
CC: Linus Torvalds <torvalds@linux-foundation.org>,
       Jing Xue <jingxue@digizenstudio.com>, linux-kernel@vger.kernel.org,
       git@vger.kernel.org
Subject: Re: git guidance
References: <20071129105220.v40i22q4gw4cgoso@intranet.digizenstudio.com> <alpine.LFD.0.9999.0711290810170.8458@woody.linux-foundation.org> <200712010950.15628.a1426z@gawab.com>
In-Reply-To: <200712010950.15628.a1426z@gawab.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2210
Lines: 44

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/