Re: [PATCH 4/3] t3700: avoid racy git situation
- From
Kristian Høgsberg <krh@redhat.com>
- Date
- Nov 8, 2007, 15:27 UTC
- Message-ID
- <1194535631.27305.3.camel@hinata.boston.redhat.com>
- In-Reply-To
- <Pine.LNX.4.64.0711081511440.4362@racer.site>
On Thu, 2007-11-08 at 15:16 +0000, Johannes Schindelin wrote:
Show 31 quoted lines
> Hi, > > On Thu, 8 Nov 2007, Johannes Sixt wrote: > > > Johannes Schindelin schrieb: > > > Wow, the builtin commit is fast. It sometimes triggers a racy > > > situation in the test case for "git add --refresh -- foo". > > > > > > So when that test fails, simply sleep one second and try again. > > > > [/me looks at the calender - no, it's not April Fool's day] > > No. The builtin commit is really that fast. > > > Wouldn't it be better to fix git-commit (or git-add)? I would like to > > help, but you already seem to have done the analysis, so... > > The problem is that the index has the same timestamp as the file "foo". > > Therefore, git cannot tell if "foo" is up-to-date in the index, since it > could have been modified (and indeed is) just a fraction of a second later > than the index was last updated. > > And since diff-index, as called from the test script, does not generate a > diff, but really only determines if the index information suggests that > the files are up-to-date, there is not really much you can do. > > This is our good old friend, the racy git problem. > > NOTE: other scms do not have this problem, mostly because they are too > slow to trigger it.
Ah, so that's what that was. Thanks for fixing that, I wasn't sure what was going on and didn't have the time to dig into it. I have a patch that fixes the author date for commit in determine_author_info() instead and fixes some of the option validation problems mentioned by Björn. I have an updated launch_editor patch too, but what you sent out looks good, so I'll just send the latest builtin-commit.
cheers, Kristian