2

Suppose I want to duplicate a bare repository. I want to back it up. It seems the canonical way to do this is with git clone --mirror. However, it also seems like you could just copy the bare repository using the OS (e.g. cp -r bare_repo bare_repo_bkp).

What exactly does git clone --mirror that differs from a recursive copy using the OS, and is it ever more or less appropriate to use one or the other?

Caleb
  • 3,839
  • 7
  • 26
  • 35
  • There are similar questions, such as https://stackoverflow.com/a/9712253/1361752. However, they are mostly focused on either `git clone` or `git clone --bare`. Or comparing `git clone --bare` to `git clone --mirror`. I couldn't fine a comparison specifically of `git clone --mirror` to `cp`, which seem (to me) to be approaching the same functionality. – Caleb Dec 17 '21 at 16:58
  • 2
    You could try it and see. Cloning copies histories of the selected refs, for mirror clones that's all of the refs, but it does not copy anything else about the setup, the new repo is freshly-made from your template with `origin` set to point to the repo it's a mirror clone of, but there's none of the origin's logs or hooks or configs or anything like that. – jthill Dec 17 '21 at 17:15

1 Answers1

1

I'll quote from a margin note in my book (which I need to get back to working on) first:

In fact, there is a fairly close relationship between system backups and version control. The key difference between the two is a function of their purpose.

Backups aim to allow you to restore anything—one file, many files, or even the entire system—after some kind of error or disaster, including loss of storage media. Backups therefore tend to be performed on a time schedule, such as hourly, daily, weekly, and so on. When backups are aimed at disaster recovery, we may delete intermediate versions, e.g., discard all hourly backups after a daily backup, then discard all daily backups after a weekly backup. In other words, backups are usually made with a system-driven point of view.

Version control systems, by contrast, aim to allow you to view or restore files from a user- and/or project-driven point of view. New versions are entered at check-in or commit time. We’ll see more about this below. If discarding old versions is allowed at all, it is also normally done with specific care, rather than according to a time schedule.

If you make backups at well-chosen times, and keep those backups forever, this does result in a form of version control. Management and comparisons of versions may prove difficult, though.

Getting more specific, git clone makes a clone of a repository, not a backup; cp -r makes a backup (under the right conditions anyway). The difference is that a clone generally copies all commits, but does not copy certain non-commit-y items, including but not necessarily limited to these:

  • references, unless you use --mirror;1
  • reflogs (even with --mirror);
  • configuration values and hooks.

Since reflogs retain nominally-deleted commits, the clone usually omits these commits as well. This is usually consider a positive, but for backup purposes, might be considered a negative.

1A non-mirror clone turns the other Git's branch references into remote-tracking names. It does, however, copy tag names, along with the copied tagged objects (usually commits and annotated tag objects), provided this is a full clone rather than a shallow one.

torek
  • 448,244
  • 59
  • 642
  • 775