Eric Kow writes: > > I find commit and log worse names than record and changes. > > I agree with what Zooko says when he points out that "commit" is a bad > name because in the DVCS setting, you're not really committing to > anything.
In some sense that's true with CVS, too; you can always revert, or branch from an older version, etc. To my mind the real problem with "commit" is that CVS cannot make distinctions among "record," "push," and "record + push". The (approximate) equation "commit = record + push" is deeply embedded in our minds by now, although "commit = record" has a toehold, too. Better to have new names for record and push. That's something Darcs got "very right" from the beginning. > The idea would probably be to accept a little worse in the name of > uniformity, the idea being that it's improbable that others will be > shifting in our direction, so maybe we go to them. The problem is that usage is so far from consistent. For example, in git "fetch" downloads the metadata and content to extend a tracking branch, but does not merge it to the current branch. "pull" does "fetch + merge". In Mercurial, it's the exact opposite. In Bazaar, all communication among different branches is done by "merge", while "pull" actually means "mirror". I do prefer "clone" to "get". It's more precise and accurate. I don't have a problem with "log". "changes" to me strongly suggests "diff" at some level, while "log" is annotated with comments by the committers. "whatchanged" suggests a list of files to me. Personally I don't have a big problem with git's habit of using "log" as a generic query command (you can get arbitrary metadata and even diffs with it), but I know that disgusts a lot of people. :-) > I agree. The problem is that everybody uses rollback/revert in > different ways, "rollback" has a precise meaning in database theory. It means to undo the last transaction (possibly incomplete) in the history. IMO Mercurial uses this correctly, Darcs does not. In general, I think that application of database terminology would be a good idea, with the exception of "commit" because of the historical context of CVS, and the very strong intuition that recording locally doesn't commit you to anything (cf. the rebase controversy, where everybody agrees that local rebasing is a mere peccadillo or even beneficial, while rebasing a branch that has been published is equated to smoking in an elevator filled with pregnant women). > As far as I understand, Mercurial's rollback is our obliterate, Pretty close, except that only the latest transaction can be rolled back in Mercurial, and once you've rolled back, you cannot roll back any more (the latest transaction is empty). > Git's revert is our rollback and our revert is Git's reset. >From Darcs's point of view, git's terminology can pretty much be ignored, as much of it refers to concepts like the index that have no meaning in branch-is-repo-is-workspace DVCSes, and the rest is idiosyncratic (cf the fetch vs. pull distinction, although it happens that I think for that one git has it right and Mercurial wrong). _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
