Re: git and time

[Shawn Pearce <spearce@spearce.org>]

Tom Prince <tom.prince@ualberta.net> wrote:
> On Wed, Sep 27, 2006 at 11:07:35PM -0400, Nicolas Pitre wrote:
> > 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.
> > 
> 
> But even knowing when the commit arrived in your local repository does
> you no good unless you are compiling every time you pull, in which case,
> the reflog support on you local machine will give you the information
> you need. Otherwise, you need to know the name of the commit you were
> running when you got bitten by the bug which is a separate issue.

Which is why Git embeds its version number from git-describe as
part of its build process.  So "git --version" can give you back
an identifier.

And given that identifier (and the new schooling given to the
sha1 expression parser) you can easily ask git to determine if the
given bug fix commit was an ancestor of that identifier, or not.
No reflog involved and you have your answer.

As it happens I build and install `next` every time I fetch from
Junio's public tree.  But I never rely on my reflog to associate
back to a commit; I always use `git --version`.

-- 
Shawn.