Documentation/git-bundle.txt: discuss naïve backups
It might be naïve to think that those who need this education would end up here in the first place. But I think it’s good to mention this high-level concept here on a command which provides a backup strategy. Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kristoffer Haugsbakk committed
Nov 16, 2024 at 15:54 UTC
820fd1a5694b8d96609590163088d3f14731b565
1 file changed
+18
Documentation/git-bundle.txt
+18
@@ -344,6 +344,24 @@ You can also see what references it offers:
344
$ git ls-remote mybundle
345
----------------
346
347
+DISCUSSION
348
+----------
349
+
350
+A naive way to make a full backup of a repository is to use something to
351
+the effect of `cp -r <repo> <destination>`. This is discouraged since
352
+the repository could be written to during the copy operation. In turn
353
+some files at `<destination>` could be corrupted.
354
+
355
+This is why it is recommended to use Git tooling for making repository
356
+backups, either with this command or with e.g. linkgit:git-clone[1].
357
+But keep in mind that these tools will not help you backup state other
358
+than refs and commits. In other words they will not help you backup
359
+contents of the index, working tree, the stash, per-repository
360
+configuration, hooks, etc.
361
+
362
+See also linkgit:gitfaq[7], section "TRANSFERS" for a discussion of the
363
+problems associated with file syncing across systems.
364
+
365
FILE FORMAT
366
-----------
367