On Sep 11, 2015, at 4:46 PM, Ron W <ronw.m...@gmail.com> wrote: > > The commit ID really is a hash. It is the hash of the manifest artifact. The > manifest's 'D Card' has the date/time stamp of the commit. Also, the > manifest's 'P card' refers to the parent commit(s). Therefore, the commit IDs > of otherwise identical child commits will be different.
That certainly explains it. I wonder if this is an implementation detail leaking through into the UI, though. Under what conditions, except for Noam’s contrived example with hardcoded dates, is there a useful distinction between “hash” — implying a number that you could reliably recompute given all the input data — and “random number”? Short of crawling the DB, you don’t have all the input data, so what does it matter how that hex string was computed? For instance, why even mention “SHA1 Hash” on the checkin details page in fossil ui, from src/info.c? Why not something more generic, like “checkin ID”? While looking into this, I see evidence of past historical wrangling here: blob.uuid, for example, even though sizeof(SHA1) != sizeof(UUID). I guess Fossil once used MD5 for these ID values, too, and not just for integrity checksumming? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
