mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48 2013-05-28 19:21:57 +00:00 • committed by admin
parent 6a188b3ef1
commit 51698e7279
1 changed files with 19 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

19
doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_4_cafcc24e98a89f10adaed5e09f75b659._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
nickname="Abdó"
subject="comment 4"
date="2013-05-28T19:21:57Z"
content="""
This \"git is afraid of .git\" issue is the main blocker for finally getting rid of unison. My use case is as follows. Among other things, I have a `~/work` directory infested with little projects versioned by git. I want to sync it between my 3 machines and a cloud server. My current setup involves star-shaped unison syncs to the server. That's not bad, but it has its problems:
* unison keeps a file index for every pair of machines (laptop-server, office-server, etc). This means that I end up with 3 identical indexes on the server, indexing the same data. Every time I sync a pair, the server rechecks what has changed to update the corresponding index.
* also, every time I add a machine, or my disk explodes and I have to setup a new unison sync from scratch, the server has to reindex everything, which is slow.
* unison does not know about the entire history, only the current state of the replicas. This may lead to data loss if I delete something I shouldn't delete and propagate. Only in special cases, for instance when I delete everything in one replica, unison asks before throwing it all out the window.
* I sometimes want to sync laptop and desktop through the local network, instead of going through the server. Then I have to be very careful in which order I do the syncs + it adds a couple of new redundant indices.
Now, git annex is not a sync tool. But as a side effect of its `git annex sync` feature, it happens to solve those issues in an elegant way, making it an extremely flexible sync tool, far superior to unison in many aspects!
Still, my `~/work` directory is infested with little git repos, so I can't use git annex on `~/work`. Also, I treat my little git projects as things carrying their own history arround. Sometimes I move them, etc. I don't want to use mr in them, nor keep remotes for all my machines on all my little projects. That removes a lot of the flexibility I'd gain by moving to git annex.
The thing is, I don't understand why this git limitation is fairly fundamental. I've been playing around nesting git repos. When I change the inner `.git` directory to `.bar`, the outer git swallows it all right, and after some playing around with commits and checkouts on the inner and outer repos, the internal repo survived the process. Also, I don't think versioning content inside `.git` may disorient git in any way. Every git call knows on which `.git` directory it operates, just go up through the path looking for the first `.git` dir which is NOT a part of the actual path. Is there anything else I am missing? Would it be feasible to patch git adding a config option that makes it treat `.git` dirs as regular dirs? I'd be willing to mess with git's source when I get the time to do it.
"""]]