summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-12-14 13:31:59 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-12-14 13:31:59 -0400
commit72484839220f90463ebeb36b07e4427140726104 (patch)
tree3567c56355164d57cd2e6bbe0cee08a3f4733bd5
parent3c851368750a5faf19ff3437854a60ae4c679c69 (diff)
parent25a5f6664ed98a20bc59bc0ca3107dd8bf7bba0b (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment20
-rw-r--r--doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment24
-rw-r--r--doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment12
-rw-r--r--doc/forum/syncing_non-git_trees_with_git-annex.mdwn46
-rw-r--r--doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment24
-rw-r--r--doc/internals.mdwn2
6 files changed, 127 insertions, 1 deletions
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment b/doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment
new file mode 100644
index 000000000..1ac9e798a
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96bb._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 4"
+ date="2011-12-13T18:16:08Z"
+ content="""
+I thought about this some more, and I think I have a pretty decent solution that avoids a central bare repository. Instead of pushing to master (which git does not like) or trying to guess the remote branch name on the other side, there is a well-known branch name, say git-annex-master. Then a sync command would do something like this (untested):
+
+ git commit -a -m 'git annex sync' # ideally with a description derived from the diff
+ git merge git-annex-master
+ git pull someremote git-annex-master # for all reachable remotes. Or better to use fetch and then merge everything in one command?
+ git branch -f git-annex-master # (or checkout git-annex-master, merge master, checkout master, but since we merged before this should have the same effect
+ git annex merge
+ git push someremote git-annex-master # for all reachable remotes
+
+The nice things are: One can push to any remote repository, and thus avoid the issue of pushing to a portable device; the merging happens on the master branch, so if it fails to merge automatically, regular git foo can resolve it, and all changes eventually reach every repository.
+
+What do you think?
+
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment b/doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment
new file mode 100644
index 000000000..0847daae9
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182e2._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 5"
+ date="2011-12-13T18:47:18Z"
+ content="""
+After some experimentation, this seems to work better:
+
+ git commit -a -m 'git annex sync'
+ git merge git-annex-master
+ for remote in $(git remote)
+ do
+ git fetch $remote
+ git merge $remote git-annex-master
+ done
+ git branch -f git-annex-master
+ git annex merge
+ for remote in $(git remote)
+ do
+ git push $remote git-annex git-annex-master
+ done
+
+Maybe this approach can be enhance to skip stuff gracefully if there is no git-annex-master branch and then be added to what \"git annex sync\" does, this way those who want to use the feature can do so by running \"git branch git-annex-master\" once. Or, if you like this and want to make it default, just make git-annex-init create the git-annex-master branch :-)
+"""]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment b/doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment
new file mode 100644
index 000000000..fc66fbb8e
--- /dev/null
+++ b/doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024ee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 6"
+ date="2011-12-13T20:53:23Z"
+ content="""
+It would be clearer to call \"git-annex-master\" \"synced/master\" (or really \"synced/$current_branch\"). That does highlight that this method of syncing is not particularly specific to git-annex.
+
+I think this would be annoying to those who do use a central bare repository, because of the unnecessary pushing and pulling to other repos, which could be expensive to do, especially if you have a lot of interconnected repos. So having a way to enable/disable it seems best.
+
+Maybe you should work up a patch to Command/Sync.hs, since I know you know haskell :)
+"""]]
diff --git a/doc/forum/syncing_non-git_trees_with_git-annex.mdwn b/doc/forum/syncing_non-git_trees_with_git-annex.mdwn
new file mode 100644
index 000000000..997378261
--- /dev/null
+++ b/doc/forum/syncing_non-git_trees_with_git-annex.mdwn
@@ -0,0 +1,46 @@
+I have a bunch of directory trees with large data files scattered over various computers and disk drives - they contain photos, videos, music, and so on. In many cases I initially copied one of these trees from one machine to another just as a cheap and dirty backup, and then made small modifications to both trees in ways I no longer remember. For example, I returned from a trip with a bunch of new photos, and then might have rotated some of them 90 degrees on one machine, and edited or renamed them on another.
+
+What I want to do now is use git-annex as a way of initially synchronising the trees, and then fully managing them on an ongoing basis. Note that the trees are *not* yet git repositories. In order to be able to detect straight-forward file renames, I believe that [[the SHA1 backend|tips/using_the_SHA1_backend]] probably makes the most sense.
+
+I've been playing around and arrived at the following setup procedure. For the sake of discussion, I assume that we have two trees `a` and `b` which live in the same directory referred to by `$td`, and that all large files end with the `.avi` suffix.
+
+ # Setup git in 'a'.
+ cd $td/a
+ git init
+
+ # Setup git-annex in 'a'.
+ echo '* annex.backend=SHA1' > .gitattributes
+ git add .gitattributes
+ git commit -m'use SHA1 backend'
+ git annex init
+
+ # Annex all large files.
+ find -name \*.avi | xargs git annex add
+ git add .
+ git commit -m'Initial import'
+
+ # Setup git in 'b'.
+ cd $td/b
+ git clone -n $td/a new
+ mv new/.git .
+ rmdir new
+ git reset # reset git index to b's wd - hangover from cloning from 'a'
+
+ # Setup git-annex in 'b'.
+ # This merges a's (origin's) git-annex branch into the local git-annex branch.
+ git annex init
+
+ # Annex all large files - because we're using SHA1 backend, some
+ # should hash to the same keys as in 'a'.
+ find -name \*.avi | xargs git annex add
+ git add .
+ git commit -m'Changes in b tree'
+
+ git remote add a $td/a
+
+ # Now pull changes in 'b' back to 'a'.
+ cd $td/a
+ git remote add b $td/b
+ git pull b master
+
+This seems to work, but have I missed anything?
diff --git a/doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment b/doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment
new file mode 100644
index 000000000..c1b9cfa37
--- /dev/null
+++ b/doc/forum/syncing_non-git_trees_with_git-annex/comment_1_7f9593bdfd95e4a8814e6cc5c44619e6._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-12-14T17:31:31Z"
+ content="""
+This is an entirely reasonable way to go about it.
+
+However, doing it this way causes files in B to always \"win\" -- If the same filename is in both repositories, with differing content, the version added in B will superscede the version from A. If A has a file that is not in B, a git commit -a in B will commit a deletion of that file.
+
+I might do it your way and look at the changes in B before (or even after) committing them to see if files from A were deleted or changed.
+
+Or, I might just instead keep B in a separate subdirectory in the repository, set up like so:
+
+<pre>
+mv b old_b
+git clone a b
+cd b
+mv ../old_b .
+git annex add old_b --exclude --not '*.avi'
+</pre>
+
+Or, a third way would be to commit A to a branch like branchA and B to a separate branchB, and not merge the branches at all.
+"""]]
diff --git a/doc/internals.mdwn b/doc/internals.mdwn
index 68cc7c3cd..b2fd1e554 100644
--- a/doc/internals.mdwn
+++ b/doc/internals.mdwn
@@ -77,7 +77,7 @@ Example:
1287290776.765152s 1 e605dca6-446a-11e0-8b2a-002170d25c55
1287290767.478634s 0 26339d22-446b-11e0-9101-002170d25c55
-These files are designed to be auto-merged using git's union merge driver.
+These files are designed to be auto-merged using git's [[union merge driver|git-union-merge]].
The timestamps allow the most recent information to be identified.
## `remote/web/aaa/bbb/*.log`