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.

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

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.

--
Andreas Ericsson                   [EMAIL PROTECTED]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
--
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/

Reply via email to