I tried to use the old thread for this, but threads don't get bumped when they are updated, so I guess I'll have to start a new one...
Here is the relevant bug report.
Here's my scenario: I have been using Dropbox for several years. I want to move to git-annex.
For some time I used Bazaar repos inside Dropbox. A couple of times I accidentally modified files on one computer before another finished syncing, and the repo became mildly corrupted, but I recovered it okay.
Recently I switched from bzr to git, and so far, so good. I'm careful not to make any changes to my files before Dropbox is finished syncing, so everything works fine.
Now I'm testing git-annex as a replacement for Dropbox again. But when I add a directory containing a git repo to an annex, git-annex ignores the .git directory, so the repo isn't synced.
I read this forum thread, and I read the bug report, but there don't appear to be any real solutions.
This seems like what should be a fairly common use case: a user has a directory of simple text files, like shell scripts or org-mode files. He uses git to version-control them, and he uses Dropbox to sync the files and the git repo automatically between computers. Now the user wants to use git-annex instead, but if he does this, it will mean having to choose between:
- No longer using git to version-control the files
- Only using git on a single system, which means that he can't make commits or do any other git operations when using other systems
- Keeping separate git repos on each system, and making the same commits manually on each one...which would be a mess
- Keeping separate git repos on each system, and using a script to make commits automatically--which would mean commits wouldn't be any more useful than a simple timed backup script
I guess I could just use git instead of Dropbox or git-annex, but then I must choose between either:
- Only being able to sync repos when both systems are online
- Having to store repos in plaintext on remote servers
This is one of my primary use cases for Dropbox/git-annex. I'd really appreciate any help in figuring this out. Thanks.
Why not just use git the way it's designed: Make a git repository on one computer. Clone to another computer. Commit changes on either whenever you like, and pull/push whenever you like. No need for any dropbox to help git sync, it can do so perfectly well on its own.
If you have a lot of repositories, see http://myrepos.branchable.com/
I continue to be unimpressed and unmotived by this use case. Posting more forum threads with the same lame reasons won't help. But at least you did say:
So, you used dropbox, and corrupted data. But that was ok. And now you're very careful to avoid doing things that will corrupt data. But that's ok. Yeah, that seems like a really good decision, given all the excellent possibilities out there.
</snark>Well, like Pere, I am rather surprised by your response, Joey. I've been an enthusiastic supporter and follower of git-annex for a long time now, and have been looking forward to using it. I didn't expect a snarky reply...and you said yourself that it was snarky. Maybe you had a bad day or something?
I don't understand why this request or idea is so controversial to you. I have several computers, and I use git to store basic text files like shell scripts and config files--a very common situation. I use Dropbox to sync them automatically between computers. I could use just git, and push/pull manually, but the whole point of having computers is for them to do things for me, automatically. The purpose of the git-annex assistant, as I understand it, is to do exactly that. Doing the push/pull manually would be a step backwards. And giving up manual control of the git repository, losing the ability to track changes to my files, would be a huge step backwards.
This seems like it must be a very common use case among Linux users, especially ones who use the shell, git, etc. If git-annex isn't good for this situation, what is? Surely there's a better way than opening a shell and running "git pull" every time I walk from one computer to the other.
I should have also mentioned, the network topology is an issue that git-annex helps solve. When my computers are on the same LAN, they could obviously sync directly with each other using git. But when they are not on the same network, or when one of them is not online, a transfer repo is needed. Dropbox and git-annex make this simple by handling it for me.
But if I did all my syncing with git manually, it could end up being quite a mess. If I took my laptop with me and left the house without syncing it first, I'd have to sync with my server on the Internet. But if I forgot to push from my desktop computer before I left, the server would be out-of-date, and I'd be stuck.
Dropbox handles this for me by automatically syncing as soon as I make changes. git-annex does the same thing, but doesn't work with nested git repos. But giving up the nested git repo would mean giving up version control of my files. As a developer, you understand why that's not an option!
Again, this seems like a very natural problem to run into, and I don't understand why it is controversial to want git-annex to handle this the way Dropbox or other sync software (e.g. SpiderOak, Wuala) can.
My, 2 cents. I used to do the same keep my git repos in Dropbox. I do not push/pull to dropbox I just keep them in there so they sync between my machines. My use case is that I am in the middle of a change and I need to switch computers (home/office) I can continue where I left of on another machine otherwise you have to make wierd commits with broken code. So IMHO it is perfectly reasonable for a single person to keep his git repo in git-annex assuming I don't use it as a central repo where other people pull push.
Plus one giant problem with git annex is that there is no way to revert a file in direct repo. It only sync and reverting to old files take a lot of effort (convert to indirect checkout commit save file to a temp location convert back to direct mode place the file back its place.) with a git repo in annex I can just use git to revert files.
On the other hand, git likes to create a lot of small files and sync them can take a lot of time. annex copies on file at a time.
That said, at one point I did experiment putting a git repo in annex for testing (using --git-dir option) it did work so it should not be that big of a deal to add the support.