Thanks for the great tool!
Is git-annex multisession compatible? I'm assuming that an "add" for example, will switch to the git-annex branch, commit data, and switch back to the previous branch. Is this protected by a Lock of some sort so that if two separate processes are interacting with the same repo/annex simultaneously there won't be any corruption?
If not, is this something I could add within my python class that is implementing the interface to the Annex?
Thanks, Mark
git-annex has quite extensive locking, so it's entirely safe to run any combination of any git-annex commands at the same time.
(It doesn't actually check out the git-annex branch when making commits to it BTW.)
Thanks Joey for the response.
This brings up two questions.
1) In my setup I have my own "sync" of just the git-annex branch with the remote after git annex operations. (I didn't want the master branch synch of "git annex sync". In this sync of mine I switch branches to do a pull/push on the git-annex branch. I found that I had to put file locks around all other git annex operations in order for things to keep from getting messed up in git. Is this because if I switch to another branch the git annex add (for example) won't work correctly even though it doesn't switch branches?
2) I could avoid the whole issue if I could "pull -rebase" and push the git-annex branch without switching branches. Is there a way to do that?
Thanks! -Mark
Well obviously if you have the git-annex branch checked out, any operation involving the work tree is not going to operate on the usual work tree. So obviously
git addandgit annex addare not going to do what you want them to do (unless you want them to add files to the checked-out git-annex branch). I'm not sure what other problems you might run into doing that.git-annex uses the .git/annex/index file to stage commits to the git-annex branch. Using that index file might help with rebasing or other operations on the branch.
It's certianly theoretically possible to rebase without touching the work tree and only using such an index file, but I don't know if git's rebase works that way. I also don't see any particular benefit to rebasing the git-annex branch.
Thanks again. Good information.
So does "git annex sync" do any branch checkout?
I'm using git annex to manage regression test outputs for audio. I don't want "git annex sync" because I want annex gets, etc. to be basically automatic. But I need to make sure when a test starts that the git-annex branch is up-to-date in case updated reference outputs were checked in elsewhere. So I want to sync the git-annex branch (but not the master because someone maybe locally testing code changes to vet the impact). I'm not a git expert, but it appears that you can't pull (or more specifically merge) outside of your working directory, so I'm simply switching branches to pull/push the git annex branch, but as we've discussed that isn't multisession safe.
So, if you're able to do the git annex sync without a branch checkout, then there is hope that I can do a subset (just a sync of the git-annex branch) without a branch checkout.
If I'm displaying a fundamental misunderstanding or missing something obvious, I'm all ears.
git annex syncdoes not check out the git-annex branch; nothing in git-annex does.git-annex checks for any remote/git-annex branches that have not been merged yet and auto-merges them, whenever it's run. So, probably all you need to do is
git fetchand possiblygit pushof the branch.Ah, that is very helpful information. I'll explore that. Any reason the fetch should not use the "+" to work with non-fast-forward updates?
I greatly appreciate your time. Thanks!
Seems to be working with "+" fetch. I did have to put the fetch before the git annex commands and the push afterward or some of the changed git state from the git annex operations was lost (for example a drop and subsequent get wouldn't work because the drop wasn't probably tracked).
Mark