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
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html