Yeah, better in terms of saving space, but I think it confuses some people, hence I didn't use it in my above example. Previous time I recommended a co-worker to use the `push to a directory` way of copying a git repository, I made them create a bare repository, and they ended up going into the directory to verify it worked and not seeing what they expected. Cue me having to explain the difference between a normal repository and a bare one. It also confused them into thinking that a bare repository isn't just another git repository but a "special" one you can sync to, while the normal one you couldn't.

So in the end, simple is simple :) Unless you're creating remote repositories at scale, you probably won't notice a difference in storage usage.

I hear all that, but --bare is necessary in this case because git (by default) won't let you push to a non-bare filesystem branch:

    ~/temp/a:master  $ git push backup
    Enumerating objects: 3, done.
    Counting objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    remote: error: refusing to update checked out branch: refs/heads/master
    remote: error: By default, updating the current branch in a non-bare repository
    remote: is denied, because it will make the index and work tree inconsistent
    remote: with what you pushed, and will require 'git reset --hard' to match
    remote: the work tree to HEAD.
    ...
    To ../b
    ! [remote rejected] master -> master (branch is currently checked out)
    error: failed to push some refs to '../b'

  git clone --mirror
  git clone --bare
  git push --mirror
  git push --all

"Is `git push --mirror` sufficient for backing up my repository?" https://stackoverflow.com/questions/3333102/is-git-push-mirr... :

> So it's usually best to use --mirror for one time copies, and just use normal push (maybe with --all) for normal uses.

git push: https://git-scm.com/docs/git-push

git clone: https://git-scm.com/docs/git-clone