On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote: > On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski <jna...@gmail.com> wrote: > > > > P.S. Having Git ensure that committerdate (as an epoch) is greater > > than committerdates of its parents at the commit creation time (with > > providing warning about time skew, perhaps not doing it if skew is > > too large) would be not costly. No need to add anything, and it would > > help future queries to be faster, I think. > > So I think git should check the committer date (ie verify that the > commitetr date of a new commit is always equal to or more recent than > all the parents). > > But we should probably allow some slop for when machines are out of > sync (think build farms etc automation that may do automated commits, > but the clocks on different machines may be off by a few seconds). We > already do things like that in some of the use of committer dates - > see for example CUTOFF_DATE_SLOP) > > And we should probably allow the user to override the refusal to > create new commits with bogus dates - think importing repositories etc > where you may have reasons to just say "that's just how it was". > > And it will take years for that to percolate out to all users, so it's > not like it will fix things immediately, but then some time from now, > we can consider commit dates to be more reliably generation numbers.
This is an assumption that might work for git repositories, but not for foreign repositories imported in git (think e.g. mercurial repositories accessed with a remote helper) Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
