开发者

Backup git repositories using fetch instead of push

开发者 https://www.devze.com 2023-01-26 16:55 出处:网络
If your git version is too old to support git push --mirror from your gitolite server is it possible to simula开发者_StackOverflow中文版te the feature by first git clone --bareing new repositories and

If your git version is too old to support git push --mirror from your gitolite server is it possible to simula开发者_StackOverflow中文版te the feature by first git clone --bareing new repositories and then using git fetch refs/*:refs/* on the backup server? Can you specify *:* as a refspec too? Since the repositories on the gitolite server are bare repos it doesn't matter if the fetch command doesn't manage to fetch objects that are only used when you have a working directory.

My recovery strategy would be to hopefully just copy the content of the backup server's $BACKUPDIR to the new gitolite server if the current one blows up. Would that also work as expected in this scenario?


This question is a bit hard to answer without installing an old version of git and checking if the solutions really work in this version. (I wouldn't know which version you are interested in anyway.) That said, I will try and give some hints on what to try, and you can check for yourself if it works for you.

  1. I don't see any reason to use git fetch instead of git push when you actually want to simulate git push --mirror.

  2. You can use *:* as a refspec (at least in recent versions of git). This is different from :, as the latter only selects the branches which exist in both repositories, while the former selects all branches on the sending site and sends them to the receiving site, creating new branches there if necessary (this holds for both, fetch and push).

  3. The closest approximation of git push --mirror $REMOTE in a single command might be

    git push -f $REMOTE *:*
    

    A difference to the "real thing" is that it never deletes branches on the remote end. You can either ignore this -- it might be quite reasonable a backup anyway -- or you can hack some code to remove them manually. Here is my (really bad) attempt at this:

    git ls-remote $REMOTE refs/* | cut -f 2 > remote-branches
    git show-ref | cut -d " " -f 2 > local-branches
    git push --delete $(join -v 1 remote-branches local-branches)
    

    I do think this attempt is fundamentally flawed -- use at your own risk. And it might not work for old versions of git anyway. (I was surprised git show-ref uses spaces as field delimiter while git ls-remote uses tabs for the same kind of output.)

0

精彩评论

暂无评论...
验证码 换一张
取 消