On Wed, Mar 3, 2010 at 2:12 PM, Bruce Stephens <bruce.stephens@xxxxxxxxx> wrote: > 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. Ah, I looked quickly ad one db and still saw 'revision_ancestry' being used. I guess they decided to keep the information redundant. >> 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). Yeah, I'm aware of the reasoning, but IMO it's too much complexity for almost no gain. It's much easier to just 'git fetch' and synchronize the changes. Anyway, good to know they updated the ancestry handling :) -- Felipe Contreras -- 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