Re: Git commit generation numbers
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Jul 15, 2011, 16:18 UTC
- Message-ID
- <CAJo=hJtuxNLhSjn_sDJxG7xu5k2wbJ_QLf_n+Z1E=o2AndAuJQ@mail.gmail.com>
- In-Reply-To
- <CA+55aFzS3KDNvKt-dXvYpuAQwFwD3+GCj8y8bRQCycPvrynT8Q@mail.gmail.com>
On Fri, Jul 15, 2011 at 09:10, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Right now, we do *have* a "generation number". It's just that it's > very easy to corrupt even by mistake. It's called "committer date". We > could improve on it.
...
> If I had realized how small the patch was to add generation counters, > and that it wouldn't have broken backwards compatibility (ie fsck > doesn't start complaining). I would have done it originally, instead > of all the crazy hacks we did for commit date verification.
What about going forward making the requirement that a new commit must have a committer date whose date is >= the maximum date of its parents?
We could also add a check during fast-forward merges to refuse to perform the merge if the incoming commit has a committer date too far forward in the future (e.g. more than 5 minutes). If you pull from a moron whose system clock is set such that the committer date isn't a proxy for generation number, Git would just refuse the merge, and you could ask them to fix their objects.
-- Shawn.