Derrick Stolee <stolee@xxxxxxxxx>: > What problem are you trying to solve where commit date is important? I don't know what Jason's are. I know what mine are. A. Portable commit identifiers 1. When I in-migrate a repository from (say) Subversion with reposurgeon, I want to be able to patch change comments so that (say) r2367 becomes a unique reference to its corresponding commit. I do not want the kludge of appending a relic SVN-ID header to be *required*, though some customers may choose that. Requirung that is an orthogonality violation. 2. Because I think in decadal timescales about infrastructure, I want my commit references to be in a format that won't break when the history is forward-migrated to the *next* VCS. That pretty much eliminates any from of opaque hash. (Git itself will have a weaker version of this problem when you change hash formats.) 3. Accordingly, I invented action stamps. This is an action stamp: <esr@xxxxxxxxxxx!2019-05-15T20:01:15Z>. One reason I want timestamp uniqueness is for action-stamp uniqueness. B. Unique canonical form of import-stream representation. Reposurgeon is a very complex piece of software with subtle failure modes. I have a strong need to be able to regression-test its operation. Right now there are important cases in which I can't do that because (a) the order in which it writes commits and (b) how it colors branches, are both phase-of-moon dependent. That is, the algorithms may be deterministic but they're not documented and seem to be dependent on variables that are hidden from me. Before import streams can have a canonical output order without hidden variables (e.g. depending only on visible metadata) in practice, that needs to be possible in principle. I've thought about this a lot and not only are unique commit timestamps the most natural way to make it possible, they're the only way conistent with the reality that commit comments may be altered for various good reasons during repository translation. > P.S. All of my (overly strong) opinions on using commit date are made > more valid when you realize anyone can set GIT_COMMITTER_DATE to get > an arbitrary commit date. In the way I would write things, you can *request* that date, but in case of a collision you might actually get one a few microseconds off that preserves its order relationship with your other commits. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
