Jeff King <peff@xxxxxxxx>: > In git, it may happen quite a bit during "git am" or "git rebase", in > which a large number of commits are replayed in a tight loop. That's a good point - a repeatable real-world case in which we can expect that behavior. This case could be solved, though, with a slight tweak to the commit generator in git (given subsecond timestamps). It could keep the time of last commit and stall by an arbitrary small amount, enough to show up as a timestamp difference. Action stamps work pretty well inside reposurgeon because they're mainly used to identify commits from older VCSes that can't run that fast. Collisions are theoretically possible but I'm never seen one in the wild. > You can > use the author timestamp instead, but it also collides (try "%at %ae" in > the above command instead). Yes, obviously for the same reason. > > And now you know why I wish git had subsecond timestamp resolution! If it > > did, uniqueness of these in a git stream could be guaranteed. > > It's still not guaranteed. Even with sufficient resolution that no two > operations could possibly complete in the same time unit, clocks do not > always march forward. They get reset, they may skew from machine to > machine, the same operation may happen on different machines, etc. Right...but the *same person* submitting operations from *different machines* within the time window required to be caught by these effects is at worst fantastically unlikely. That case is exactly why action stamps have an email part. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> -- 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