I would understand if you answer 'y' to one but 'n' to the other
it would result in a situation with unmatching .pack and .idx
and you would see something like the above (by the way, the
"fatal" is coming from update-server-info that tries to read
from freshly moved packfiles); but the above is different, so it
does not explain the symptom. I am worried and curious as to
what happened, since you are answering 'y' to both of them.
This would trigger immediately after a clone which creates pack
and idx unwritable; repack leaves the results writable unless
your umask is 0222, so "mv" would not even ask the silly
questions.
Did you happen to have .tmp-pack-ce49d2ef... at the project root
level after this failure? If so which one (either .pack or .idx)?
If you had .tmp-pack-*.pack then .git/objects/pack/pack-ce49...pack
is from the old round and .git/objects/pack/pack-ce49...idx is
from the new one. Moving .tmp-pack-* to .git/objects/pack/pack-*
would hopefully solve this problem.
Nevertheless, this _is_ a dangerous and grave bug, and thanks
for reporting it.
Maybe we would want to do something like this:
-- >8 --
git-repack: Be careful when updating the same pack as existing one.
After clone, packfiles are read-only by default and "mv" went
interactive asking if the user wants to replace it with a
repacked copy. If one is successfully moved and the other is
not, the pack and its idx would become out-of-sync and corrupts
the repository.
Recovering is straightforward -- it is just the matter of
finding the remaining .tmp-pack-* and make sure they are both
moved -- but we should be extra careful not to do something so
alarming to the users.
---
diff --git a/git-repack.sh b/git-repack.sh
index eb75c8c..b58cf91 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -54,9 +54,21 @@ else
fi
mkdir -p "$PACKDIR" || exit
- mv .tmp-pack-$name.pack "$PACKDIR/pack-$name.pack" &&
- mv .tmp-pack-$name.idx "$PACKDIR/pack-$name.idx" ||
- exit
+ for sfx in pack ...
