diff options
| author |  Joey Hess <joey@kitenet.net> | 2013-07-09 15:08:59 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2013-07-09 15:08:59 -0400 |
| commit | 38ca87d9a33107d162398d2b9a2d79a8a5ea967e (patch) | |
| tree | e3df1ea85dd262bcf589d39f727864b0beddfae0 /doc/sync.mdwn | |
| parent | fd23b3ac4fb99850e017694e48ceb2538143c935 (diff) | |
break out a page
Diffstat (limited to 'doc/sync.mdwn')
| -rw-r--r-- | doc/sync.mdwn | 29 |
1 files changed, 5 insertions, 24 deletions
diff --git a/doc/sync.mdwn b/doc/sync.mdwn index 52beddf9a..ade34d48d 100644 --- a/doc/sync.mdwn +++ b/doc/sync.mdwn @@ -17,10 +17,11 @@ Breitner. The idea is to have a branch `synced/master` (actually, 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. 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. +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 @@ -35,23 +36,3 @@ The workflow for using `git annex sync` is simple: * 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. - -## automatic merge conflict resolution - -The sync process involves merging a branch into your currently checked out -branch. This could lead to a merge conflict, perhaps because the same file -got changed in two different ways. An extra feature of `git annex sync` is -that it automatically resolves these merge conflicts, rather than leaving -git in the middle of a conflicted merge. - -If this occurs, there will be several messages printed about the merge -conflict, and the file that has the merge conflict will be renamed, with -".variant-XXX" tacked onto it. So if there are two versions of file foo, -you might end up with "foo.variant-AAA" and "foo.variant-BBB". It's then -up to you to decide what to do with these two files. Perhaps you can -manually combine them back into a single file. Or perhaps you choose to -rename them to better names and keep two versions, or delete one version -you don't want. - -The "AAA" and "BBB" in the above example are essentially arbitrary -(technically they are the MD5 checksum of the key). |