* race condition after calling git reset --keep
@ 2019-01-15 12:57 Thibault Kruse
0 siblings, 0 replies; only message in thread
From: Thibault Kruse @ 2019-01-15 12:57 UTC (permalink / raw)
To: git
Hi,
trying to wrap git, I ran into this problem using git 2.17.1 on Ubuntu 18.04.1.
When fast-forwarding like this:
git reset --keep remotes/origin/master
sometimes git returns an error like:
error: Entry 'foo.txt' not uptodate. Cannot merge.
fatal: Could not reset index file to revision 'remotes/origin/master'.
...in situations where fast-forward would seem possible at a glance.
This can have different root causes as mentioned in
* https://stackoverflow.com/questions/1248029
* https://stackoverflow.com/questions/878554
We are not sure what causes this for our users, one contributing
factor seems to be git repositories that have not been updated in a
long time (maybe last update with a different git version).
In our case this can apparently often be prevented by calling e.g.
git update-index -q --refresh
When trying to unit-test our solution I found a way to reproduce the
symptom, but I ran into what looks like a race-condition.
To reproduce, on a file that is changed on the remote branch, I run
chmod u+x file
git reset --keep ...
chmod u-x file
git reset --keep ...
This makes the both git commands fail, though occasionally the second
one succeeds (hence I assume a race condition).
I am posting this here not because I need an urgent patch, but because
this might not be intentional and thus possibly a bug, and as shown in
the stackoverflow question other users may be affected, and the
non-deterministic behavior on race conditions is of course making
matters worse.
To reproduce a git error below, a sleep is required after a first call
to git reset --keep, so that the next call to git reset --keep after a
file permission change fails.
#! /usr/bin/env sh
set -e
# this script shows a race condition in git reset --keep
# It can be repeatedly run without manual cleanup
# it creates / deletes folders 'parent' and 'child' in /tmp
# setup origin with two commits on file foo.txt
cd /tmp
git init parent
cd parent/
touch foo.txt
git add foo.txt
git commit -m foo || true
echo 'hello' > foo.txt
git add foo.txt
git commit -m foo2 || true
cd ..
rm -rf child # cleanup previous runs
# Clone repo master branch, reset hard to first commit, mess with
file permissions
git clone parent child
cd child/
git reset --hard HEAD~1
chmod u+x foo.txt
# next line always fails, which seems legit
git reset --keep remotes/origin/master || true
# This sleep is required to make the last command fail. Without
sleep, the last git command succeeds most of the time
sleep 1
chmod u-x foo.txt
# Next line should fail? Sometimes it does, sometimes not.
git reset --keep remotes/origin/master
regards,
Thibault Kruse
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-01-15 12:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-15 12:57 race condition after calling git reset --keep Thibault Kruse
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).