Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
7248483922
6 changed files with 127 additions and 1 deletions
|
|
@ -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?
|
||||
|
||||
"""]]
|
||||
|
|
@ -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 :-)
|
||||
"""]]
|
||||
|
|
@ -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 :)
|
||||
"""]]
|
||||
46
doc/forum/syncing_non-git_trees_with_git-annex.mdwn
Normal file
46
doc/forum/syncing_non-git_trees_with_git-annex.mdwn
Normal file
|
|
@ -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?
|
||||
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
@ -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`
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue