Hello,
On Thu, Sep 17, 2015 at 2:57 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Thu, Sep 17, 2015 at 3:08 AM, Giuseppe Bilotta
> <giuseppe.bilotta@xxxxxxxxx> wrote:
>
>> A somewhat problematic git bisect has allowed me to identify commit
>> 03b86647722f11ccc321cd7279aa49b811d17cc2 as the first bad commit.
>
> That commit is mostly refactoring, but there's one extra lock added in
> these hunks. Maybe you can revert it and see if it improves anything.
>
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 87439fa..5e13444 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -3644,7 +3644,7 @@ static void build_fake_ancestor(struct patch
> *list, const char *filename)
> {
> struct patch *patch;
> struct index_state result = { NULL };
> - int fd;
> + static struct lock_file lock;
>
> /* Once we start supporting the reverse patch, it may be
> * worth showing the new sha1 prefix, but until then...
> @@ -3682,8 +3682,8 @@ static void build_fake_ancestor(struct patch
> *list, const char *filename)
> die ("Could not add %s to temporary index", name);
> }
>
> - fd = open(filename, O_WRONLY | O_CREAT, 0666);
> - if (fd < 0 || write_index(&result, fd) || close(fd))
> + hold_lock_file_for_update(&lock, filename, LOCK_DIE_ON_ERROR);
> + if (write_locked_index(&result, &lock, COMMIT_LOCK))
> die ("Could not write temporary index to %s", filename);
>
> discard_index(&result);
This is not trivial to revert because write_index isn't available
anymore. I'm not sure what I should replace it with.
>> The problem has all signs of a timing issue, which I'm having problems
>> isolating, although simply providing a timeout on the index lock calls
>> seems to fix it.
>
> lockfile has received some updates lately. This commit caught my eyes,
> 044b6a9 (lockfile: allow file locking to be retried with a timeout -
> 2015-05-11), but this is just a shot in the dark..
The point is that, if I add a timeout to the checkout lock, it works.
It works as if something locks it earlier, and the unlock doesn't
register quickly enough, so waiting a few tens of milliseconds makes
it work.
> So it fails at "git checkout". That'll give me something to look in
> git-rebase*.sh. Thanks.
For what it's worth, the problem seems easier to replicate with a very
long list of commits than with a short one.
Best regards,
--
Giuseppe "Oblomov" Bilotta
--
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