Page MenuHomephabricator

Redesign the resync logic
Open, NormalPublic


The current repo resync implementation had a major flaw: when there were pending commits in Phabricator, the sync script would produce bogus resync commits. The reason is that for resync we utilize the same code path as the ordinary sync, and we do git pull as often as possible to reduce the possibility of unresolvable conflicts. However, when resyncing, we don't just look at the on-wiki edits, but also compare the page contents with the repo files. Thus, if there are pending commits in Phabricator, they get pulled and then, naturally, there is a difference between the wiki and the repo (what the pulled commits changed), but the resync algorithm erroneously considers these as out-of-sync problem and tries to "fix" them.

The core of the problem is that when a resync is requested, we do it first, while in fact we should do it last, after the sync in both directions has already been finished.

Event Timeline

kerberizer triaged this task as Normal priority.Nov 8 2018, 6:21 PM
kerberizer created this task.
kerberizer created this object with edit policy "Phabricator maintenance (Project)".