Andreas Ericsson wrote: > Al Boldi wrote: > > Phillip Susi wrote: > >> Al Boldi wrote: > >>> 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. > > > > Whether git uses the client/server model or not does not matter; what > > matters is that there are two distinct use-cases at work here: one on > > the server/repository, and the other on the client. > > Git is distributed. The repository is everywhere. No server is actually > needed. Many use one anyway since it can be convenient. It's not, however, > necessary. 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. > >> 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. > > > > Again, this only handles the interface to/from the server/repository, > > but once you pulled the sources, it leaves you without Version Control > > on the client. > > No, that's CVS, SVN and other centralized scm's. With git you have perfect > version control on each peer. That's the entire idea behind "fully > distributed". As explained before in this thread, replicating the git tree on the client still doesn't provide the required transparency. > > By pulling the sources into a git-client manager mounted on some dir, it > > should be possible to let the developer work naturally/transparently in > > a readable/writeable manner, and only require his input when reverting > > locally or committing to the server/repository. > > 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. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
