--- Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > > - So exported data is never/rarely in an inconsistent state with respect to commit order and > > local time order (data integrity). > > Pick one. You can't have "never" and "rarely". I mean "rarely" in the sense that there is no guarantee that local time is exact but any inexactness would be confined locally. > Track it by version, not timestamp. Know what commit or tag SHA1 > was used to produce that binary. Ask GIT if the fix is in that > SHA1 ancestory or not. I've already said that on this thread. So you are saying time, even local commit time, is completely unnecessary? I disagree. Git doesn't need to keep track of any times in a distributed way, it just might be worthwhile to keep track of local commit timestamps internally per repo. > I think they care more about what release of the kernel will have > that driver. That can easily be determined by the DAG and by > understanding what branch(es) will wind up in the next release and > doing simple math: "Lets see, current release is version 2.6.9000, > so it will be in 2.6.9001." Even if people care more about "what release" that doesn't mean they don't care about (local commit) time. -Matt __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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