Re: git guidance

From: Phillip Susi <psusi@cfl.rr.com>
Date: Dec 6, 2007, 21:46 UTC
Message-ID: <47586DB0.5040706@cfl.rr.com>
In-Reply-To: <200712072155.04643.a1426z@gawab.com>

Al Boldi wrote:

> When you read server, don't read it as localized; a server can be 
> distributed.  What distinguishes a server from an engine is that it has to 
> handle a multi-user use-case.  How that is implemented, locally or remotely 
> or distributed, is another issue.

And again, git handles both use cases, so what's your point?

> As explained before in this thread, replicating the git tree on the client 
> still doesn't provide the required transparency.

It has been pointed out to you that it DOES. Either that or nobody else understands your nebulous use of "transparency" so maybe you should define it like we've been asking you. Furthermore, the comment you replied to said nothing about transparency, nor did your comment it was in reply to; rather it was pointing out the fact that your statement that the git can not perform version control on the client is patently false.

Show 10 quoted lines

>> How is that different from what every SCM, including git, is doing today?
>> The user needs to tell the scm when it's time to take a snapshot of the
>> current state. Git is distributed though, so committing is usually not the
>> same as publishing. Is that lack of a single command to commit and publish
>> what's nagging you? If it's not, I completely fail to see what you're
>> getting at, unless you've only ever looked at repositories without a
>> worktree attached, or you think that git should work like an editor's
>> "undo" functionality, which would be quite insane.
> 
> You need to re-read the thread.

Perhaps you should. We have been trying to get you to explain how you think git isn't "transparent" while at the same time pointing out how we think it is. You have failed to demonstrate any evidence to back up your claims, all of which have been shown to be false.