git and time

On Wed, Sep 27, 2006 at 10:04:04PM -0400, Sean wrote:

> > I actually understand that and agree. All I've
been saying is it
> > (git or gitweb.cgi) should prefer the local
timestamp rather than
> > any "remote" timestamps for no other
reason than to minimize the
> > possibility of timestamps being grossly
inaccurate.
> 
> But any local time stamp would be a _lie_.  The time
stamp in the
> commit records when it was actually created.  And as
Junio has
> pointed out, hundreds of commits will typically arrive
in a repo at
> the exact same time.  Your suggestion would have them
all showing
> the exact same time.  That's not helpful, and it loses
important
> factual information.

There are two issues here.  Could a git tree record the
local time
that each commit entered the repository?  Sure.  Someone who
wanted to
hack up git so that it created a local db file associating
the SHA
hash name of the commit with when it arrived in its local
repository.
It would not be part of the "true" git repository
information, and it
could be something which is optional in the sense that if
the
information is lost, it's not the end of the world,
vis-a-vis correct
git functioning.

The second question, though, is would it be *useful*? 
Presumably this
would be an option, so the user could request to see the
time when a
commit hit a particular repository, as well as when the
commit was
first created --- or perhaps both.

The problem though is that this could easily get confusing,
since it
adds a distinction (which repository am I talking to?) which
normally
doesn't exist in git.  And it forces us to make explicit
things that
normally are kept hidden --- such as whether or not Linus
does his
work directly on the git tree which is exposed by
master.kernel.org,
or whether he does the work on his own local tree, and then
pushes the
changes to master.kernel.org.  

In git, we believe that all repositories are equal, and that
any sense
that a particular repository is the "master" or
the "mainline" is
strictly speaking, a matter of convention.  What Matthew I
think is
asking for is direct support in git for that notion.

So it *could* be done, but whether or not it is a good idea
or worth
the complexity is a different question.  One could imagine a
completely different protocol, which exported the contents
of the
hypothetical db database described above.  So for
maintainers that
were *important*, and who were willing to make this
information
available, given a particular SHA hash of a commit, one
could ask the
question, "when did this commit first eneter your
repository"?

Matthew seems hung up on on desperately wanting to know this
information as it relates to a particular repository ---
Linus's.
This is in fact different from when the commit hit the
repository
which is master.kernel.org which is why the local commit
times on
master.kernel.org wouldn't be useful.  

HOWEVER, if it was judged important enough, and worth the
complexity
that it would add to git, the ability to track when a commit
entered a
particular repository and the ability to export it via some
kind of
web interface certainly be implemented.  Linus would then
have to
decide whether this was information he felt like making
available to
inquisitive seekers wanting to know this sort of info.

						- Ted
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- Theodore Tso <tytsomit.edu> wrote:

> In git, we believe that all repositories are equal, and
that any sense
> that a particular repository is the "master"
or the "mainline" is
> strictly speaking, a matter of convention.  What
Matthew I think is
> asking for is direct support in git for that notion.

No. I merely think git should try harder to ensure that
commit order is consistent with time
order, it really should (somehow) be impossible for git and
gitweb.cgi to have commit dates ~2
days in the future. I think replication is a separate issue.
In a distributed system the only
"time" that makes any sense or is the most
relevant in many situations and most importantly is the
only thing that can be semi-trusted is local time.
"Creation date" is basically just random text
someone entered, there is no guarantee and you are tempting
inconsistent time order. And git
shouldn't be so fragile as to need each and every git server
to have time set semi-correctly, but
I guess it's a bigger deal to non-developers as we actually
use time and also believe even web
interfaces should have consistency and integrity. 

-Matt

-Matt

-Matt
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Matthew L Foster wrote:
> --- Theodore Tso <tytsomit.edu> wrote:
> 
>> In git, we believe that all repositories are equal,
and that any sense
>> that a particular repository is the
"master" or the "mainline" is
>> strictly speaking, a matter of convention.  What
Matthew I think is
>> asking for is direct support in git for that
notion.
> 
> No. I merely think git should try harder to ensure that
commit order is consistent with time
> order, it really should (somehow) be impossible for git
and gitweb.cgi to have commit dates ~2
> days in the future. I think replication is a separate
issue. In a distributed system the only
> "time" that makes any sense or is the most
relevant in many situations and most importantly is the
> only thing that can be semi-trusted is local time.
"Creation date" is basically just random text
> someone entered, there is no guarantee and you are
tempting inconsistent time order. And git
> shouldn't be so fragile as to need each and every git
server to have time set semi-correctly, but
> I guess it's a bigger deal to non-developers as we
actually use time and also believe even web
> interfaces should have consistency and integrity. 
> 
> -Matt
> 

See, the confusion here seems to be that you think that not
caring about 
the time attached to a commit for anything more than a
heuristic makes 
git fragile.

I think that the rest of the git developers prefer to see
this as a 
feature that makes git more robust in the face of something
that they 
might not have any control over (or desire to control).

That said, if *you* are managing a repository, it shouldn't
be difficult 
to enforce the kind of rule that you are asking for. Simply
implement a 
pre-commit hook that checks all commits that will be added
to *your* 
repo to make sure that time is monotonically increasing from
the last 
commit, and that it does not pass "now".

So if you receive a commit from a developer that violates
this rule, you 
can send the commit back to them with a request to fix their
system 
time, and recreate the patch/series.

I just don't think that any of the kernel developers feel
the need to 
police any one else's clocks . . . they're more interested
in the 
contents of the patch.

Regards,

Rogan

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- Rogan Dawes <discarddawes.za.net> wrote:

> I just don't think that any of the kernel developers
feel the need to 
> police any one else's clocks . . . they're more
interested in the 
> contents of the patch.

I am not saying git should "police any one else's
clocks", I am saying git should be designed or
configured in such a way, using local time, that it obviates
the current reliance on everyone
else's clock being set correctly. 

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

On Thu, 28 Sep 2006, Matthew L Foster wrote:
> 
> I am not saying git should "police any one else's
clocks", I am saying git should be designed or
> configured in such a way, using local time, that it
obviates the current reliance on everyone
> else's clock being set correctly. 

Matt!

THERE IS NO SUCH RELIANCE! NONE.

Trust me. When we say that git ignores time, WE MEAN IT. Git
does not rely 
on time, git does not use time, git does not CARE!

Please stop looking at gitweb _immediately_. If you think
time has some 
meaning for git, stop. It doesn't. We've told you over and
over and over 
again that there is absolutely _zero_ reliance on everybody
else's clock 
being set correctly. The damn clock could go _backwards_, or
make huge 
jumping purple leaps of imagination, and git wouldn't care.

The time that git records is purely a random number. It's a
random number 
that _humans_ can choose to care about or not, and it's a
random number 
that git itself uses only in the sense of "ok, I've got
two equal choices, 
let's toss a coin to select which one I'll look at
next", BUT IT IS A 
RANDOM NUMBER.

Please.

Download a local git archive, and run "gitk" on
that archive. Then _hide_ 
the time column (just so that it doesn't confuse you), and
then _look_ at 
the leftmost column which shows the CAUSALITY DAG!

THAT is what git actually cares about. It's the _only_ thing
that git 
cares about. Git cares about _causality_, not time. Nothing
else matters.

Really. Truly, pretty please, I promise you, cross my heart
and hope to 
die! Scouts honor. Lock it up and throw away the key. It's
TRUE.

		Linus


-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Linus Torvalds <torvaldsosdl.org> writes:

> On Thu, 28 Sep 2006, Matthew L Foster wrote:
>> 
>> I am not saying git should "police any one
else's clocks", I am saying git should be designed or
>> configured in such a way, using local time, that it
obviates the current reliance on everyone
>> else's clock being set correctly. 
>
> Matt!
>
> THERE IS NO SUCH RELIANCE! NONE.
>
> Trust me. When we say that git ignores time, WE MEAN
IT. Git does not rely 
> on time, git does not use time, git does not CARE!
>
> Please stop looking at gitweb _immediately_. If you
think time has some 
> meaning for git, stop. It doesn't. We've told you over
and over and over 
> again that there is absolutely _zero_ reliance on
everybody else's clock 
> being set correctly. The damn clock could go
_backwards_, or make huge 
> jumping purple leaps of imagination, and git wouldn't
care.

I think Matthew means (by "relying") that
everybody's clock must
be set correctly in order for us to show the commits in
gitweb
or rev-list output so that their timestamps are
monotonically
decreasing (because we list things from newer to older).  I
sympathise.

We order things by causality (i.e. ancestry order), but that
unfortunately (!!)  happens to match timestamp order for
simple
history made on a single machine.  This can easily lead to
such
a misunderstanding that we are somehow trying to show things
in
linear time order, hence we subscribe to the notion of
global,
uniform and monotonic time.

Of course, we don't.

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

> Trust me. When we say that git ignores time, WE MEAN
IT. Git does not rely 
> on time, git does not use time, git does not CARE!

I understand that git doesn't care about time internally as
it treats it as a random number for
people to care about or not on their own, I am only saying
that local time is more likely to be
cared about than disparate remote creation times. 

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. 

-Matt


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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?

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

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.

I really don't think the thing you ask for exists.

Don't get me wrong. You _can_ have a local time for each
commit that 
tracks "when did this commit show up in this particular
branch". Git 
already supports that, even if gitweb cannot show it, and in
fact showing 
it would be very hard (since the exact same commit can often
exist in 
multiple different branches, you'd have to show multiple
times: in Junios 
"git" tree you often have a commit that showed up
in the "next" branch 
three weeks ago, but in the "master" branch only
yesterday).

The _problem_ with this is that it makes the whole concept
of time 
meaningless. It's pointless. You can do it, but I guarantee
you that once 
you actually use it for a while, you'll want to go back.
There are several 
reasons for that:

 - it means that the -same- exact project, when looked at
frm two 
   different sites that mirror it, have totally different
times. In other 
   words, the times have become pointless for something like
gitweb.

 - it means that all times will be seriously
"compressed", in that you'll 
   find hundreds (or thousands) of commits that just have
the same 
   timestamp. You could try to "spread them out"
by just making up some 
   totally arbitrary mapping function, but that would
basically have 
   absolutely no basis in anything that has any relationship
to "reality"

So it just doesn't make any sense.

The only thing that makes sense is that in your private
repository (that 
is _not_ exported to others through "gitweb" or
something like that), you 
can ask yourself the question:

	"What did my tree look like yesterday before I went
out for a 
	 beer, and came back drunk as a toad, and screwed
everything up?"

And the thing is, you can do that already. Just say

	git log "master{18 hours ago}"

and git will hopefully show you (assuming you had enabled
ref-logging as 
described earlier in this thread) exactly what you wanted.

See? 

But it does not make sense in _any_ other setting. Certainly
not gitweb.

			Linus
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- Johannes Schindelin <Johannes.Schindelingmx.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).

- To encourage people to care about/prefer local commit time
rather than remote creation/emailed
time

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

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

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Matthew L Foster <mfoster167yahoo.com> wrote:
> --- Johannes Schindelin <Johannes.Schindelingmx.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.
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

torsdag 28 september 2006 19:11 skrev Linus Torvalds:
> The time that git records is purely a random number.
It's a random number
> that _humans_ can choose to care about or not, and it's
a random number
> that git itself uses only in the sense of "ok,
I've got two equal choices,
> let's toss a coin to select which one I'll look at
next", BUT IT IS A
> RANDOM NUMBER.

I'd think of it as comment, about as (un)reliable as the
author field or the 
descriptive free-form comment people enter when they commit.
It's not even 
necessarily the local system time if GIT_AUTHOR_DATE has
been set.

-- robin
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Matthew L Foster wrote:
> --- Rogan Dawes <discarddawes.za.net> wrote:
> 
>> I just don't think that any of the kernel
developers feel the need to 
>> police any one else's clocks . . . they're more
interested in the 
>> contents of the patch.
> 
> I am not saying git should "police any one else's
clocks", I am saying git should be designed or
> configured in such a way, using local time, that it
obviates the current reliance on everyone
> else's clock being set correctly. 

Sounds like you're suggesting that Git should not record any
timestamps 
at all. After all, Git doesn't need them.
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- A Large Angry SCM <gitzillagmail.com> wrote:

> Sounds like you're suggesting that Git should not
record any timestamps 
> at all. After all, Git doesn't need them.

Yeah kind of, since distributed git doesn't need timestamps
and can't guarantee them the only time
that might make any sense to use locally is local commit
time. 

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- A Large Angry SCM <gitzillagmail.com> wrote:

> Sounds like you're suggesting that Git should not
record any timestamps 
> at all. After all, Git doesn't need them.

Yeah kind of, since distributed git doesn't need timestamps
and can't guarantee them the only time
that might make any sense to use locally is local commit
time. 

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Matthew L Foster wrote:
> --- A Large Angry SCM <gitzillagmail.com> wrote:
> 
>> Sounds like you're suggesting that Git should not
record any timestamps 
>> at all. After all, Git doesn't need them.
> 
> Yeah kind of, since distributed git doesn't need
timestamps and can't guarantee them the only time
> that might make any sense to use locally is local
commit time. 

There is no local commit time for things you get from a
remote repository.

When I wrote "Sounds like you're suggesting that Git
should not record 
any timestamps at all", I meant _you_ don't think Git
should record 
_any_ timestamps since they can't be guaranteed to match the
DAG.
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- Shawn Pearce <spearcespearce.org> wrote:

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

I mean "rarely" in the sense that there is no
guarantee that local time is exact but any
inexactness would be confined 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.

So you are saying time, even local commit time, is
completely unnecessary? I disagree. Git doesn't
need to keep track of any times in a distributed way, it
just might be worthwhile to keep track of
local commit timestamps internally per repo.

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

Even if people care more about "what release" that
doesn't mean they don't care about (local
commit) time.

-Matt


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- A Large Angry SCM <gitzillagmail.com> wrote:

> There is no local commit time for things you get from a
remote repository.

Are you saying it's impossible to internally record/track
local commit/merge time for things you
get from a remote repository, ref-log?

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

--- A Large Angry SCM <gitzillagmail.com> wrote:

> There is no local commit time for things you get from a
remote repository.

Are you saying it's impossible to internally record/track
local commit/merge time for things you
get from a remote repository, ref-log?

-Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

Matt,

what exactly are you trying to achieve here? Is this a sort
of contest who 
can have the longest thread on gitvger.kernel.org?

If you really want to understand why git does not rely on
timestamps, and 
why it should not, and why you can still be happy
nevertheless, there are 
enough answers in this thread.

Hth,
Dscho

-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html