[PATCH] dim: Make rr-cache more robust

[Daniel Vetter]

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 at intel.com>
---
 dim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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
-- 
2.13.3