Re: topological index field for commit objects

From: Jakub Narębski <jnareb@gmail.com>
Date: Jun 30, 2016, 23:39 UTC
Message-ID: <5775ADA0.3000906@gmail.com>
In-Reply-To: <CA+55aFy2AEe7ew5Px=2Uit6hraGV9zFr=JZ57rSYXWMQ4nMjeg@mail.gmail.com>

W dniu 2016-06-30 o 20:12, Linus Torvalds pisze:

Show 17 quoted lines

> On Thu, Jun 30, 2016 at 3:30 AM, Jakub Narębski <jnareb@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
> committer 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).

The problem with this idea is that the clock skew might be in two directions, but it does fix/help only one. If committer's clock lags behind true time, the automatic bump to have committerdate of a new commit be greater than committerdates of all its parent is quite helpful.

However, if some developer has his or her clock misconfigured so that it gives time in the future, this feature would not help. Commits from such developer (from such machine) would screw it up for others.

That's why I think some limit is needed. For example, if for some reason commit was created with committer date 3 days in the future, we would probably do not want for other developers to have to lie about when they created their commit.

Or did you mean that if the date for new commit is in the past of committerdates of its parents, its all right when it is within 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".

Right. I was thinking about (ab)using --no-verify flag, or perhaps prompting user if the terminal is interactive. But perhaps a separate flag / environment variable would be better...

> 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.

[...]

That's the idea of the proposal.

-- 
Jakub Narębski