Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: [...] > That's not exactly correct. Monotone works very differently; a > revision doesn't include the ancestry, that's handled in a separate > structure, so the revision hash doesn't tell you anything about the > ancestry. Not so. Long ago that was the case (ancestry was via certs), but that's not been the case for a long time. There are (in retrospect) obvious advantages in including the ancestry in the hash. > In fact, a revision doesn't contain anything, the data is handled by > "certs", and certs can be added later. Revisions lack date, author, branch, commit message, but include ancestry and the actual changes (which files/directories have changed and how). > For example, it's possible to clone a repository and then add a second > commit message to a bunch of revisions. The revision hash doesn't > change. Instead, they ensure security by signing every piece of data > about a commit (commit date, author, commit message). So it's possible > to have multiple commit dates, authors, messages, etc. each signed by > a different person. > > I'm not really fond of this approach :P It has the nice feature that many people can create merges, and if they create exactly the same merge (from exactly the same parents) then only one revision results (just with multiple certs decorating it). (Monotone has changed since I last used it but I think the above is still true. There's been discussion about larger certs (rather than having separate certs for branch, date, author, message, to have just one covering the usual combination) AFAIK that hasn't happened yet.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html