Re: bug in name-rev on linux-2.6 repo?

[tytso@mit.edu]

On Thu, Apr 22, 2010 at 11:20:34AM -0700, Linus Torvalds wrote:
> On Thu, 22 Apr 2010, Jonathan Nieder wrote:
> >
> > Hi Ted, [ nip ]
> > 
> > It seems that the committer date is set to coincide with the author
> > date for ext4 patches, which breaks some assumptions by git that each
> > commit has a later or equal committer date than all parents (modulo
> > some skew).
> 
> Argh. Yeah, that's just _evil_. Admittedly, git should never care, but in 
> practice it does, because doing the whole graph walk can be _very_ 
> expensive. So git wants to think that the committer dates at least have 
> _some_ real-life significance.
>
> > How is the ext4 tree generated from your patch queue?

Argh, sorry, I didn't realize git cared.  I didn't realize it was
doing optimizations based on the committer dates.

I'm using guilt to generate the ext4 tree.  The realize why I like
guilt is that keep the patch queue stored in git, both for revision
history purposes and because it allows other people to see and
potentially collaborate on the patch queue maintenance.

A long time ago (as in years), I put in a feature request to the guilt
maintainer that the author and committer dates should be set from the
file modtimes.  This has the property that when I go back and forth
between commits, it doesn't generate excess garbage for git to deal
with, since with the author and committer dates the same, if I do a
"guilt pop" followed by a "guilt push", the commit id of HEAD stays
the same.

So far, so good, until it happens that I decide I need to rewind the
patch queue and update a patch description (maybe to add a kernel
bugzilla entry, or an tested-by, etc.)  Since that touches the
modtime, you can end up with crazy date sequences such as this:

Sun Jan 24 14:34:07 2010 -0500 19f5fb7
Mon Dec 7 10:36:20 2009 -0500 d2eecb0
Fri Jan 1 01:00:21 2010 -0500 f8ec9d6
Wed Dec 23 07:45:44 2009 -0500 71f2be2
Fri Jan 22 17:40:42 2010 -0500 1f2acb6
Mon Feb 15 20:17:55 2010 -0500 15121c1
Thu Feb 4 23:58:38 2010 -0500 a1de02d

In any case, I didn't realize this causes problems, so I can add some
manual processing to make sure this doesn't happen in the future, and
I can look into hacking guilt so that enforces the invariant that the
commiter time/date must always be increasing.

Sorry about causing problems,

					- Ted