| Message ID | 20170721162627.23304-1-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/dim b/dim index de3264aa0f76..53771762f15d 100755 --- a/dim +++ b/dim @@ -512,9 +512,9 @@ function commit_rerere_cache if git_is_current_branch rerere-cache ; then remote=$(branch_to_remote rerere-cache) - git pull >& /dev/null rm $(rr_cache_dir)/rr-cache -Rf &> /dev/null || true cp $(rr_cache_dir)/* rr-cache -r --preserve=timestamps + git pull >& /dev/null git add ./*.patch >& /dev/null || true for file in $(find rr-cache/); do if ! git log --since="60 days ago" --name-only -- $file | grep $file &> /dev/null; then
There's a failure mode I didn't take into account: 1. You start a dim rebuild-tip, and update your rr-cache. Because you didn't push for a while, this adds some really old files (but with today's timestamp). 2. 2nd person finished their dim rebuild-tip and garbage-collects the old rr-cache entries. 3. We get to commit_rr_cache, and the first thing the script does is update the rr-cache branch, which deletes the old entries. 4. Then we copy them over again, because their timestamp is fresh. 5. The filtering doesn't catch them, because git ls-files doesn't list them (they're deleted files after all). 6. They get re-added right away. I think this is what happend today between Chris and Imre, and resulted in a bit of confusion. I think if we pull only after copying this would be avoided, since the pull would delete the files the 2nd person gc'ed in step 2, and so prevents them from getting re-added. Worst case there's a functional conflict and the pusher needs to clean up the mess. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> --- dim | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)