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

From: tytso@mit.edu <tytso@mit.edu>
Date: Apr 24, 2010, 23:04 UTC
Message-ID: <20100424230415.GA667@thunk.org>
In-Reply-To: <alpine.LFD.2.00.1004221119290.26046@i5.linux-foundation.org>

On Thu, Apr 22, 2010 at 11:20:34AM -0700, Linus Torvalds wrote:

Show 15 quoted lines

> 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