Re: [PATCH 2/2] commit: use a priority queue in merge base functions

From: Jeff King <peff@peff.net>
Date: Aug 30, 2012, 13:03 UTC
Message-ID: <20120830130327.GB5687@sigill.intra.peff.net>
In-Reply-To: <20120830125421.GA5687@sigill.intra.peff.net>

On Thu, Aug 30, 2012 at 08:54:21AM -0400, Jeff King wrote:

Show 10 quoted lines

> On Wed, Aug 29, 2012 at 05:05:40PM -0400, Jeff King wrote:
> 
> > You would want this on top:
> > [...]
> > but t6024 still fails (it clearly is finding a different merge base than
> > the test expects).  I'll trace through it, but it will have to be later
> > tonight.
> 
> The problem in t6024 is caused by the fact that the commit timestamps
> for every commit are identical.

So I was able to have my queue behave just like commit_list by fixing the stability issue. But I still have no clue what is going on in t6024. It does this for each commit it makes:

  [...]
  GIT_AUTHOR_DATE="2006-12-12 23:00:00" git commit -m 1 a1 &&
  [...]
  GIT_AUTHOR_DATE="2006-12-12 23:00:01" git commit -m A a1 &&
  [...]

which is just bizarre. At first I thought it was buggy, and that it really wanted to be setting COMMITTER_DATE (in which case it should really just be using test_tick, anyway). But if you do that, the test fails (even using a regular commit_list)!

So is the test buggy? Or are the identical commit timestamps part of the intended effect? I can't see how that would be, since:

  1. You would need to set COMMITTER_DATE for that anyway, as you are
     otherwise creating a race condition.

  2. Why would you set AUTHOR_DATE? It's not used by the merge code at
     all.

The script originally comes from here:

  http://thread.gmane.org/gmane.comp.version-control.git/33566/focus=33852

and the discussion implies that the AUTHOR_DATEs were added to avoid a race condition with the timestamps. But why would that ever have worked?

Confused...

-Peff