lkml.org 
[lkml]   [2007]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: git guidance
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.

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




\
 
 \ /
  Last update: 2007-12-06 22:49    [from the cache]
©2003-2011 Jasper Spaans