| Message ID | 20211020010624.675562-5-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Additional FAQ entries | expand |
On 20/10/21 08.06, brian m. carlson wrote: > +Be aware that even with these recommendations, syncing in this way is > +potentially risky since it bypasses Git's normal integrity checking for > +repositories, so having backups is advised. > + This raises question: how users can backup their repos? The answer is same as this FAQ for syncing working trees: have your repo to be pushed to the spare server at disposal, or use rsync (as long as the preconditions are met).
On 20/10/2021 05:58, Bagas Sanjaya wrote: > On 20/10/21 08.06, brian m. carlson wrote: >> +Be aware that even with these recommendations, syncing in this way is >> +potentially risky since it bypasses Git's normal integrity checking for >> +repositories, so having backups is advised. >> + > > This raises question: how users can backup their repos? The answer is > same as this FAQ for syncing working trees: have your repo to be > pushed to the spare server at disposal, or use rsync (as long as the > preconditions are met). > Perhaps, for backing up a repo, users might be pointed toward `git bundle` (with caveats about `--all` being over complete..)
On Wed, Oct 20 2021, brian m. carlson wrote: > +The recommended approach is to use `rsync -a --delete-after` (ideally with an > +encrypted connection such as with `ssh`) on the root of repository. You should > +ensure several things when you do this: What's the reason to recommend --delete-after in particular? I realize that e.g. in the .git directory not using *A* delete option *will* cause corruption, e.g. if you can leave behind stale loose refs with an up-to-date pack-refs file. But isn't that equally covered by --delete and --delete-before? I'm not very well worsed in rsync, but aren't the two equivalent as far as the end-state goes? If the intention with --delete-after over --delete or --delete-before is to somehow make the repository useful during the transfer, doesn't that go against the later advice of: > +* The repository is in a quiescent state for the duration of the transfer (that > + is, no operations of any sort are taking place on it, including background > + operations like `git gc`). Also for this: > +Be aware that even with these recommendations, syncing in this way is > +potentially risky since it bypasses Git's normal integrity checking for > +repositories, so having backups is advised. Perhaps we should recommend running a "git gc" or other integrity check after (or "git fsck"), although those don't cover some cases, e.g. the pack-refs v.s. loose refs problem in the case of a missing --delete-whatever.
On 2021-10-20 at 23:35:43, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Oct 20 2021, brian m. carlson wrote: > > > +The recommended approach is to use `rsync -a --delete-after` (ideally with an > > +encrypted connection such as with `ssh`) on the root of repository. You should > > +ensure several things when you do this: > > What's the reason to recommend --delete-after in particular? I realize > that e.g. in the .git directory not using *A* delete option *will* cause > corruption, e.g. if you can leave behind stale loose refs with an > up-to-date pack-refs file. > > But isn't that equally covered by --delete and --delete-before? I'm not > very well worsed in rsync, but aren't the two equivalent as far as the > end-state goes? Yes. The goal is that if something goes wrong, you have all the objects you did before, even if you have some potentially invalid refs. The goal is to make it a little less risky if you interrupt it with a Ctrl-C because you realize the destination contained data you wanted. I always prefer --delete-after for that reason, assuming the destination has sufficient disk space. It shouldn't make a difference in a successful end state, however. > > > +Be aware that even with these recommendations, syncing in this way is > > +potentially risky since it bypasses Git's normal integrity checking for > > +repositories, so having backups is advised. > > Perhaps we should recommend running a "git gc" or other integrity check > after (or "git fsck"), although those don't cover some cases, e.g. the > pack-refs v.s. loose refs problem in the case of a missing > --delete-whatever. I can recommend something like that.
On Thu, Oct 21 2021, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > On 2021-10-20 at 23:35:43, Ævar Arnfjörð Bjarmason wrote: >> >> On Wed, Oct 20 2021, brian m. carlson wrote: >> >> > +The recommended approach is to use `rsync -a --delete-after` (ideally with an >> > +encrypted connection such as with `ssh`) on the root of repository. You should >> > +ensure several things when you do this: >> >> What's the reason to recommend --delete-after in particular? I realize >> that e.g. in the .git directory not using *A* delete option *will* cause >> corruption, e.g. if you can leave behind stale loose refs with an >> up-to-date pack-refs file. >> >> But isn't that equally covered by --delete and --delete-before? I'm not >> very well worsed in rsync, but aren't the two equivalent as far as the >> end-state goes? > > Yes. The goal is that if something goes wrong, you have all the objects > you did before, even if you have some potentially invalid refs. The > goal is to make it a little less risky if you interrupt it with a Ctrl-C > because you realize the destination contained data you wanted. I always > prefer --delete-after for that reason, assuming the destination has > sufficient disk space. Isn't it preferable to recommend --delete-before for that reason? I.e. --delete-after will produce subtle corruption of e.g. refs potentially pointing to the wrong thing. But if you recommend --delete-before I think (but maybe I'm missing some cases) that it will be more likely to produce obvious corruption, e.g. git dying due to missing objects. Anyway, I'm also happy to just leave this as-is, it just stood out to me as od.. > It shouldn't make a difference in a successful end state, however. >> >> > +Be aware that even with these recommendations, syncing in this way is >> > +potentially risky since it bypasses Git's normal integrity checking for >> > +repositories, so having backups is advised. >> >> Perhaps we should recommend running a "git gc" or other integrity check >> after (or "git fsck"), although those don't cover some cases, e.g. the >> pack-refs v.s. loose refs problem in the case of a missing >> --delete-whatever. > > I can recommend something like that. ...or just leave it as-is is also fine with me, whatever you think is best.
diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt index 85ac99c7b2..4a8a46f980 100644 --- a/Documentation/gitfaq.txt +++ b/Documentation/gitfaq.txt @@ -83,8 +83,8 @@ Windows would be the configuration `"C:\Program Files\Vim\gvim.exe" --nofork`, which quotes the filename with spaces and specifies the `--nofork` option to avoid backgrounding the process. -Credentials ------------ +Credentials and Transfers +------------------------- [[http-credentials]] How do I specify my credentials when pushing over HTTP?:: @@ -185,6 +185,45 @@ Then, you can adjust your push URL to use `git@example_author` or `git@example_committer` instead of `git@example.org` (e.g., `git remote set-url git@example_author:org1/project1.git`). +[[sync-working-tree]] +How do I sync a working tree across systems?:: + First, decide whether you want to do this at all. Git usually works better + when you push or pull your work using the typical `git push` and `git fetch` + commands and isn't designed to share a working tree across systems. Doing so + can cause `git status` to need to re-read every file in the working tree. + Additionally, Git's security model does not permit sharing a working tree + across untrusted users, so it is only safe to sync a working tree if it will + only be used by a single user across all machines. ++ +Therefore, it's better to push your work to either the other system or a central +server using the normal push and pull mechanism. However, this doesn't always +preserve important data, like stashes, so some people prefer to share a working +tree across systems. ++ +It is important not to use a cloud syncing service to sync any portion of a Git +repository, since this can cause corruption, such as missing objects, changed +or added files, broken refs, and a wide variety of other corruption. These +services tend to sync file by file and don't understand the structure of a Git +repository. This is especially bad if they sync the repository in the middle of +it being updated, since that is very likely to cause incomplete or partial +updates and therefore data loss. ++ +The recommended approach is to use `rsync -a --delete-after` (ideally with an +encrypted connection such as with `ssh`) on the root of repository. You should +ensure several things when you do this: ++ +* There are no additional worktrees enabled for your repository. +* You are not using a separate Git directory outside of your repository root. +* You are comfortable with the destination directory being an exact copy of the + source directory, _deleting any data that is already there_. +* The repository is in a quiescent state for the duration of the transfer (that + is, no operations of any sort are taking place on it, including background + operations like `git gc`). ++ +Be aware that even with these recommendations, syncing in this way is +potentially risky since it bypasses Git's normal integrity checking for +repositories, so having backups is advised. + Common Issues -------------
Users very commonly want to sync their working tree across machines, often to carry across in-progress work or stashes. Despite this not being a recommended approach, users want to do it and are not dissuaded by suggestions not to, so let's recommend a sensible technique. The technique that many users are using is their preferred cloud syncing service, which is a bad idea. Users have reported problems where they end up with duplicate files that won't go away (with names like "file.c 2"), broken references, oddly named references that have date stamps appended to them, missing objects, and general corruption and data loss. That's because almost all of these tools sync file by file, which is a great technique if your project is a single word processing document or spreadsheet, but is utterly abysmal for Git repositories because they don't necessarily snapshot the entire repository correctly. They also tend to sync the files immediately instead of when the repository is quiescent, so writing multiple files, as occurs during a commit or a gc, can confuse the tools and lead to corruption. We know that the old standby, rsync, is up to the task, provided that the repository is quiescent, so let's suggest that and dissuade people from using cloud syncing tools. Let's tell people about common things they should be aware of before doing this and that this is still potentially risky. Additionally, let's tell people that Git's security model does not permit sharing working trees across users in case they planned to do that. While we'd still prefer users didn't try to do this, hopefully this will lead them in a safer direction. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- Documentation/gitfaq.txt | 43 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-)