It seems that right now we're unconditionally forcing 'git reset --hard' for no good reason, and then using 'git-restore-mtime' to fix mtimes of files (copying commit timestamps). However, given that we don't really verify commit timestamps, there's no guarantee that mtimes will be anywhere near sane. Putting aside the possibility of intentional timestamp manipulation (git provides envvars to set their values), two developers committing in a short time with small enough clock drifts can result in a newer commit having older timestamp than its parent. If both commits affect the same file, it can even cause mtime going back in time. Then there's the risk of server clock time() being earlier than mtimes which can cause all kinds of minor issues. For full tree signing with incremental updates, having monotonous timestamps is important. I think we should really work towards using a regular 'git pull' whenever possible, and relying on regular mtime updates. 'git reset --hard' should be only necessary if force push is done (i.e. almost never), and even if that happens I suppose one full rsync will be the least of our problems.
I need to dig out the older bugs, but the original problem started because rsync didn't have enough timestamp resolution, and some of the Manifest changes were not being propagated to clients: file size remained the same, mtime was within the same second.
I don't see how that would be relevant. Even if we assume that our scripts are fast enough to immediately thicken the Manifest within a single second after git update, the mirrors shouldn't be likely to fetch the interim state.
(In reply to Michał Górny from comment #2) > I don't see how that would be relevant. Even if we assume that our scripts > are fast enough to immediately thicken the Manifest within a single second > after git update, the mirrors shouldn't be likely to fetch the interim state. It was going out to mirrors sometimes :-(. One of the things I considered for this, was to make the git tree with metadata become the official source for rsync mirrors. The only concern I had in this is getting better atomic checkouts without forcing mtime jumps on unchanged files.
Can't we establishing some kings of locking for this?
