Samuel A. Falvo II writes: > Holy criminey, this is one extremely hard to use tool.
It says right on the label that git is not a tool. It's a library implemented as shell commands so that tools can be written as shell scripts. Many common tasks are very easy to implement. For example: > If you "git clone" the repository again to another location, the newly > updated data was there. But in the original repository, the web page > still showed the old contents!! To get the effect you want, probably all you need to do is create a file in the website repo called $GIT_DIR/hooks/post-update, containing #!/bin/sh git checkout master You have every right to want a SCM that does that for you, and many other things that would *not* be trivial to implement in git. On the other hand, git does a lot of things well, and it does almost everything fast. With the addition of many convenience commands in recent versions, it works better for me than Darcs does. Jason Dagit writes: > Samuel A. Falvo II writes: > > However, git has something darcs doesn't yet have -- stability and > > speed. > Given your experience with git I don't understand why you give it > points for stability. Sounds to me like it did the wrong thing plain > and simple. I have a hard time thinking of that as stable. If I were > in your shoes I wouldn't trust git. No, it didn't do what he thought it would do. However, what it does do is accurately documented. git push updates refs, ie, pointers to heads of branches. It is not an inverse to git pull, which *also* merges the workspace, but rather to git fetch. Maybe a better name would be "git deliver". (Curiously enough, monotone people seem to think that it is git fetch that is badly named; git pull should be named git update, and git fetch named git pull.) If you want to define "trust" as "it almost always does what I want and expect", that's fine, and will work great for most users. But that's a different issue from stability as normally defined, which is "consistently does what it promises to do and did in the past." Stability is a problem with Darcs. Conflicts can (and in my experience with Darcs up to v1.0.7) often did leave me in a wedged state, where Darcs would spin indefinitely. Recovering was often messy and uncertain, unlike "git reset" (which doesn't affect the workspace unless you specify "--hard"). Speed is a very big disadvantage for Darcs compared to git or mercurial. Nor do I really experience any advantages to patch theory. In theory, it's a cool theory. In practice, "branch early, rebase often" gives equivalent convenience in git for my use cases. I still use Darcs for existing small projects, but new ones all end up in git. :-( > I remember reading something a while back about git not always > doing the right thing with histories. Bit of a design problem if I > recall correctly. I think one of the monotone developers pointed > this out to me. Is this related? http://www.mail-archive.com/[EMAIL PROTECTED]/msg08033.html If so, there's a long discussion of trust models in the git man page. Basically, since a version (commit object) hashes the parent's name and the workspace tree, a single hash can verify the history as well as the content. There are admitted weaknesses, but I would call it a design choice rather than a problem. _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
