Re: git and time

[Nicolas Pitre <nico@cam.org>]

On Wed, 27 Sep 2006, Junio C Hamano wrote:

> As Shawn said in a nearby thread, in a public and prominent
> repository like kernel.org repository it may sometimes be
> interesting and useful to know when each commit became available
> on each branch.  I am reasonably sure that it would not however
> make gitweb output easier to read to order its output by that
> timestamp.   Linus pulls from subsystem maintainers all the time
> and one pull may bring in dozens of commits, and they will get
> the same timestamp if you did so.  Actually it is worse than
> that.  He tends to batch, so he would have many such pulls and
> patch applications in his private repository, perhaps over a few
> hour, but the result will be pushed out to kernel.org with one
> push operation.  To show the "truthful" time, your gitweb would
> give the timestamp of that push operation for hundreds of
> commits pushed out during that operation.
> 
> I do not personally think that would be useful at all.  And I
> happen to know how expensive to teach gitweb to produce such an
> output, so I would not seriously suggest anybody to try it.

I beg to differ.  Such information might be really useful.  I agree 
though that this is an expensive operation and gitweb might not be the 
best place for it at all.

For example... some times I look at git-log output and finds about a 
certain bug fix that was apparently committed a month ago.  And 
incidentally I recall having been bitten by that bug not really long 
ago, say last week.  Although the bug fix was committed _somewhere_ last 
month, what I would really want to know is just when _i_ received that 
bug fix in my own repository to determine if it was before or after last 
week.  So if it was before last week then I could conclude that the bug 
fix didn't actually fix my bug.  Knowing that it has been committed last 
month is absolutely useless to me in this case.


Nicolas