Re: git and time

[Shawn Pearce <spearce@spearce.org>]

Matthew L Foster <mfoster167@yahoo.com> wrote:
> --- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> > On Thu, 28 Sep 2006, Matthew L Foster wrote:
> > 
> > > It should be possible to export git data, through say a web interface, 
> > > in a such a way that local time order is consistent with commit order.
> > 
> > Why?
> 
> - So exported data is never/rarely in an inconsistent state with respect to commit order and local
> time order (data integrity).

Pick one.  You can't have "never" and "rarely".
 
> - To encourage people to care about/prefer local commit time rather than remote creation/emailed
> time

Why?  In general I don't care about time in Git.  Maybe I care about
when I authored something if my wife wants to know why I was up until
6 am the night before ("Look honey, I was coding until 6:00 am! See
the commit!") but otherwise I don't find time to be that interesting.

Then again I don't find time in the real world that intersting
either.  I'm either where I'm supposed to be or I'm not and I'll
get there when I get there.

> - So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was
> committed/merged locally

Track it by version, not timestamp.  Know what commit or tag SHA1
was used to produce that binary.  Ask GIT if the fix is in that
SHA1 ancestory or not.  I've already said that on this thread.
 
> - In many situations "history" is incomplete without local commit time. If a company has a new
> driver they would probably prefer to know when the main kernel repo has it, not when they
> created/emailed it or when a remote repo committed it.

I think they care more about what release of the kernel will have
that driver.  That can easily be determined by the DAG and by
understanding what branch(es) will wind up in the next release and
doing simple math: "Lets see, current release is version 2.6.9000,
so it will be in 2.6.9001."

-- 
Shawn.