Re: [PATCH] guilt: Make sure the commit time is increasing
- From
Erik Faye-Lund <kusmabite@googlemail.com>
- Date
- Jul 6, 2010, 15:02 UTC
- Message-ID
- <AANLkTikWGzEq8wiVyu_xJ-tK92N1oRFOrawjOe9UQXkr@mail.gmail.com>
- In-Reply-To
- <20100706142921.GB6666@sigill.intra.peff.net>
On Tue, Jul 6, 2010 at 4:29 PM, Jeff King <peff@peff.net> wrote:
Show 29 quoted lines
> On Tue, Jul 06, 2010 at 03:53:56PM +0200, Erik Faye-Lund wrote: > >> > At one point rev-list did require monotonic --- i.e., the committer >> > date of each commit had to be equal to or later than that of each of >> > its parents) with no clock skew but that was considered a bug and >> > fixed by v1.5.5-rc1~16 (Make revision limiting more robust against >> > occasional bad commit dates, 2008-03-17) >> > >> >> This might be a stupid question, but I'm not entirely clear on why >> it's not a strict requirement; surely it would be easy to ensure that >> the commit-time is at least as big as the parents when generating the >> commit...? >> >> Is it to avoid the case where a user commits with the clock set to >> some point (potentially far) in the future, so all subsequent commits >> would have the same, artificially high commit time? Or is there some >> other reason I can't think of? > > You can have clock skew between distributed developers. So imagine you > commit at 5:00pm, then I pull at 5:01pm, but it turns out your clock is > two minutes fast, so it's actually 4:59pm. > > What should my commit do? If I insist on monotonic increases, then my > clock gets pushed forward artificially by your fast, broken clock (which > is probably not the end of the world; in practice, if your clock is N > seconds fast, there will presumably be some N second period where I'm > not making a commit, and the clocks can "catch up" with each other). >
Yeah, but this doesn't really answer my question; as you're saying, it's probably not the end of the world, at least when the skew is low.
But I can imagine it becoming a big deal when the skew is high. The again, perhaps this should constitute a "bad commit" and commit should error out if a parent commit was more than some number of minutes newer than the current time (or whatever)? That way, skewed commits would be caught early if a developer is working with other people, and a lot of the traversal could perhaps be faster (or more robust). If the developer with the skewed clock doesn't work with anyone, skew isn't really a problem, but perhaps he'd have to do some branch-filtering to un-skew commits when starting to work with others. And only if the skew is really high... like, multiple days... Which can't really be THAT common?
However, turning a technical problem that already have a solution that seems to work for everyone into a social one might be a bad idea. I'm really just thinking out loud here :)
-- Erik "kusma" Faye-Lund