Thread (12 messages) flat view 12 messages, 5 authors, 2016-06-15

Re: [RFH] revision limiting sometimes ignored

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:44:10

Possibly related (same subject, not in this thread)

Hi,

On Tue, 5 Feb 2008, Linus Torvalds wrote:
I really wonder if the right thing is not simply to admit that we consider 
the commit time meaningful (within some fudge factor!), and then do:

 - make commit warn if any parent commit date is in the future from the 
   current commit date (allow a *small* fudge factor here, say 5 minutes).
5 minutes seems a little narrow to me.  I think we can even go with 86400 
seconds.
 - teach fsck to complain about parent commits being in the future from 
   their children (allow the same small fudge factor).

 - make the revision walking code realize that if times are too close to 
   each other, it should walk a bit further back...
There is one big problem, though.  Sometimes your clock is set wrong for 
all the wrong reasons.  Look at

	http://article.gmane.org/gmane.comp.version-control.git/67848/raw

for example (look at the Original-Date).  If that happens without being 
noticed (and it happened here!), and it is pushed, you have to live with 
it.

_However_, I could imagine that you can get most of such errors by doing 
the same as gmane: realise that the clock skew is into the future, and 
just take the sensible date.

In our case, this would mean that the revision walker should realise that 
a child whose date is not older than its parent commit must be wrong.  And 
just take the parent's date instead (but maybe only for the purpose of 
limiting).

Hmm?

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help