e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # imported from the archive
44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
The `git annex sync` command provides an easy way to keep several
|
|
repositories in sync.
|
|
|
|
Often git is used in a centralized fashion with a central bare repository
|
|
which changes are pulled and pushed to using normal git commands.
|
|
That works fine, if you don't mind having a central repository.
|
|
|
|
But it can be harder to use git in a fully decentralized fashion, with no
|
|
central repository and still keep repositories in sync with one another.
|
|
You have to remember to pull from each remote, and merge the appropriate
|
|
branch after pulling. It's difficult to *push* to a remote, since git does
|
|
not allow pushes into the currently checked out branch.
|
|
|
|
`git annex sync` makes it easier using a scheme devised by Joachim
|
|
Breitner. The idea is to have a branch `synced/master` (actually,
|
|
`synced/$currentbranch`), that is never directly checked out, and serves
|
|
as a drop-point for other repositories to use to push changes.
|
|
|
|
When you run `git annex sync`, it merges the `synced/master` branch
|
|
into `master`, receiving anything that's been pushed to it. (If there is a
|
|
conflict in this merge, [[automatic_conflict_resolution]] is used to
|
|
resolve it). Then it fetches from each remote, and merges in any changes that
|
|
have been made to the remotes too. Finally, it updates `synced/master`
|
|
to reflect the new state of `master`, and pushes it out to each of the remotes.
|
|
|
|
This way, changes propagate around between repositories as `git annex sync`
|
|
is run on each of them. Every repository does not need to be able to talk
|
|
to every other repository; as long as the graph of repositories is
|
|
connected, and `git annex sync` is run from time to time on each, a given
|
|
change, made anywhere, will eventually reach every other repository.
|
|
|
|
The workflow for using `git annex sync` is simple:
|
|
|
|
* Make some changes to files in the repository, using `git-annex`,
|
|
or anything else.
|
|
* Run `git annex sync` to save the changes.
|
|
* Next time you're working on a different clone of that repository,
|
|
run `git annex sync` to update it.
|
|
|
|
Note that by default, `git annex sync` only synchronises the git
|
|
repositories, but does not transfer the content of annexed files. If you
|
|
want to fully synchronise two repositories content,
|
|
you can use `git annex sync --content`. You can also configure
|
|
[[preferred_content]] settings to make only some content be synced.
|