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. > 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. 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. Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
