Al Boldi wrote:
Judging an idea, based on a flawed implementation, doesn't prove that the
idea itself is flawed.
It isn't the implementation that is flawed, it is the idea. The entire
point of a change control system is that you explicitly define change
sets and add comments to the set. The filesystem was designed to allow
changes to be made willy-nilly. If your goal is to perform change
control only with filesystem semantics, then you have a non starter as
their goals are opposing. Requiring an explicit command command is
hardly burdensome, and otherwise, a git tree is perfectly transparent to
non git aware tools.
Sure, you wouldn't want to change the git-engine update semantics, as that
sits on the server and handles all users. But what the git model is
currently missing is a client manager. Right now, this is being worked
around by replicating the git tree on the client, which still doesn't
provide the required transparency.
It isn't missing a client manager, it was explicitly designed to not
have one, at least not as a distinct entity from a server, because it
does not use a client/server architecture. This is very much by design,
not a work around.
What transparency are you requiring here? You can transparently read
your git tree with all non git aware tools, what other meaning of
transparency is there?
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. 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.
--
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
