Karsten Blees [off-list ref] writes:
Problem 1: Failure to detect racy files (without USE_NSEC)
==========================================================
Git may not detect racy changes when 'update-index' runs in parallel
to work tree updates.
Consider this (where timestamps are t<seconds>.<nanoseconds>):
t0.0$ echo "foo" > file1
t0.1$ git update-index file1 & # runs in background
I just wonder after looking at the ampersand here ...
Please let me know what you think of this...maybe I've completely
screwed up and can no longer see the forest for all the trees.
... if your task would become much simpler if you declare "once you
give Git the control, do not muck with the repository until you get
the control back".
Am 28.09.2015 um 19:38 schrieb Junio C Hamano:
Karsten Blees [off-list ref] writes:
quoted
Problem 1: Failure to detect racy files (without USE_NSEC)
==========================================================
Git may not detect racy changes when 'update-index' runs in parallel
to work tree updates.
Consider this (where timestamps are t<seconds>.<nanoseconds>):
t0.0$ echo "foo" > file1
t0.1$ git update-index file1 & # runs in background
I just wonder after looking at the ampersand here ...
quoted
Please let me know what you think of this...maybe I've completely
screwed up and can no longer see the forest for all the trees.
... if your task would become much simpler if you declare "once you
give Git the control, do not muck with the repository until you get
the control back".
This is just to illustrate the problem. GUI-based applications will
often do things in the background that you cannot control. E.g. gitk,
git gui, Eclipse or TortoiseGit don't tell you when and how long you
shouldn't touch the working copy. At the same time, IntelliJ IDEA and
most office suits have the auto-save feature turned on by default,
and you cannot tell them when *not* to auto-save.
It may still be quite unlikely that this happens (you need two
changes within a second, without changing the file size), but *if*
it happens, the user may not even notice. And as git trusts the
false stat data blindly, the problem won't go away automatically.
You can mark all entries racy by setting index mtime to some value
far in the past, but this implies that you noticed that something
was wrong...