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

> 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

The script originally comes from here:


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?


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

Reply via email to