{"thread":{"id":"50227","subject":"race condition after calling git reset --keep","startedAt":"2019-01-15T12:57:32Z","lastAt":"2019-01-15T12:57:32Z","messageCount":1,"participants":["Thibault Kruse"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366707","messageId":"CAByu6UVQgEiP1D4n1MzPe8ApCwpm_spc6apreOhLOWbExxyVXQ@mail.gmail.com","threadId":"50227","inReplyTo":null,"subject":"race condition after calling git reset --keep","fromName":"Thibault Kruse","fromEmail":"tibokruse@googlemail.com","sentAt":"2019-01-15T12:57:17Z","receivedAt":"2019-01-15T12:57:32Z","isPatch":false,"sender":{"key":"tibokruse@googlemail.com","avatar":"https://gravatar.com/avatar/68c46b980bae1554690b4e334db8e5102b7fc25afae6bba2fdf48ce1243cc0c6?d=mp&s=160"},"body":"Hi,\n\ntrying to wrap git, I ran into this problem using git 2.17.1 on Ubuntu 18.04.1.\nWhen fast-forwarding like this:\n\n    git reset --keep remotes/origin/master\n\nsometimes git returns an error like:\n\n    error: Entry 'foo.txt' not uptodate. Cannot merge.\n    fatal: Could not reset index file to revision 'remotes/origin/master'.\n\n...in situations where fast-forward would seem possible at a glance.\n\nThis can have different root causes as mentioned in\n* https://stackoverflow.com/questions/1248029\n* https://stackoverflow.com/questions/878554\n\nWe are not sure what causes this for our users, one contributing\nfactor seems to be git repositories that have not been updated in a\nlong time (maybe last update with a different git version).\n\nIn our case this can apparently often be prevented by calling e.g.\n\n    git update-index -q --refresh\n\nWhen trying to unit-test our solution I found a way to reproduce the\nsymptom, but I ran into what looks like a race-condition.\n\nTo reproduce, on a file that is changed on the remote branch, I run\n\n    chmod u+x file\n    git reset --keep ...\n    chmod u-x file\n    git reset --keep ...\n\nThis makes the both git commands fail, though occasionally the second\none succeeds (hence I assume a race condition).\nI am posting this here not because I need an urgent patch, but because\nthis might not be intentional and thus possibly a bug, and as shown in\nthe stackoverflow question other users may be affected, and the\nnon-deterministic behavior on race conditions is of course making\nmatters worse.\n\nTo reproduce a git error below, a sleep is required after a first call\nto git reset --keep, so that the next call to git reset --keep after a\nfile permission change fails.\n\n    #! /usr/bin/env sh\n\n    set -e\n\n    # this script shows a race condition in git reset --keep\n    # It can be repeatedly run without manual cleanup\n    # it creates / deletes folders 'parent' and 'child' in /tmp\n\n    # setup origin with two commits on file foo.txt\n    cd /tmp\n    git init parent\n    cd parent/\n    touch foo.txt\n    git add foo.txt\n    git commit -m foo || true\n    echo 'hello' > foo.txt\n    git add foo.txt\n    git commit -m foo2 || true\n\n    cd ..\n    rm -rf child # cleanup previous runs\n\n    # Clone repo master branch, reset hard to first commit, mess with\nfile permissions\n    git clone parent child\n    cd child/\n    git reset --hard HEAD~1\n    chmod u+x foo.txt\n    # next line always fails, which seems legit\n    git reset --keep remotes/origin/master || true\n    # This sleep is required to make the last command fail. Without\nsleep, the last git command succeeds most of the time\n    sleep 1\n    chmod u-x foo.txt\n    # Next line should fail?   Sometimes it does, sometimes not.\n    git reset --keep remotes/origin/master\n\n\nregards,\n  Thibault Kruse\n"}]}