EDIT 2015-04-30:
anarcat escreveu um guia para este caso de uso que ele postou nos comentários para esta resposta.
EDIT 2013-05-31:
Obrigado por aceitar! gioele apontou nos comentários que reinject não funciona em repos de git anexo de modo direto, o que faz sentido, e meio que tira o vento da minha resposta. O slm encontrou um método alternativo usando git annex add , com o qual Gioele se parece. Confira a resposta de slm para mais informações sobre isso.
Original
Não ouvi falar do git anexo; essa é uma ferramenta legal!
Ok, pelo que li no site do git annex, no novo computador você pode fazer git clone do repositório S3 e não será caro, já que é apenas copiar links simbólicos. Então cd e git annex init <reponamehere> como de costume para fazer git anexo ciente do repo.
reinject que eu acho que vai fazer o que você quer:
git annex reinject /path/to/files/* /path/to/repo
Você pode querer adicionar a opção --fast que pode desabilitar o "fsck" (termo do git annex para checagem de checksum dos arquivos) que é executado automaticamente por reinject . Isso, obviamente, é um pouco perigoso e pode até não funcionar: não está claro se reinject aceita --fast ou não.
Além disso, você pode precisar de algum tipo de find one-liner se os arquivos que você deseja reinject forem mais complicados do que um único diretório. Algo como:
find /path/to/files/* -type f -exec bash -c 'echo $1 "/path/to/repo/${1#/path/to/files}"' -- '{}' \;
Esse (eu acho) ecoará o caminho de todos os arquivos em /path/to/files enquanto ecoando um caminho de destino em seu repositório com /path/to/files removidos. Substitua echo por git annex reinject depois de executá-lo e você tem certeza de que a saída está fazendo o que você pretende. Usar find em conjunto com bash -c traz grande poder e grande responsabilidade :)
Fonte: trabalhando em um trabalho de análise de dados que envolve uma quantidade hilariante de operações em lote em arquivos, e praticamente apaixonado pelo git.