--- Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> Well, there i sno "wrong" time. There are just "different" times. The only
> thing git really tracks is not actually the time (that's purely for human
> consumption), but the *relationship* between commits. So git really very
> fundmanetally just tracks things like "commit X was the parent of commit
> Y", and the time is really immaterial.
Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and
use the time merge C happened locally for both instead of using the time commits X and Y were
created? It seems to me changes showing up as being made long before they really were merged is a
very serious problem verification wise but if everyone is using git then perhaps it's not as bad
as I think. What happens when security bug fix Z errantly seems to be in v2.6.22 but in reality
its not?
Thanks for the responses,
-Matt
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
-
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
