summaryrefslogtreecommitdiff
path: root/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment
diff options
context:
space:
mode:
Diffstat (limited to 'doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment')
-rw-r--r--doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment30
1 files changed, 30 insertions, 0 deletions
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment
new file mode 100644
index 000000000..df97625f7
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
+ nickname="Abdó"
+ subject="comment 8"
+ date="2013-11-22T18:44:35Z"
+ content="""
+> I am not convinced at all that it makes any sense to try to sync git repositories in this way
+
+I agree this is not a good solution.
+
+
+> I realize that some people drop git checkouts into dropbox and use that, but it's a fundamentally unsound thing to do, and those people are just lucky if they manage to avoid running into problems doing that.
+
+Well, I don't use dropbox (nor annex assistant) but I sync a lot of git repos with unison. It is not luck, it is being careful not to create conflicts. I agree this is not ideal, and I'm looking for a better way to deal with this.
+
+
+> Also, this feature would only be used by a small number of users
+
+I'm not convinced of that. If done right, nested git repos inside annex could have value.
+
+Let's say you work with 40 git repos some private of yours, others tracking upstream, and you want to sync them across 4 machines (home, work, cloud server, backup). I imagine your preferred solution would be to configure the 4 machines as remotes on every git repo and use mr, am I right?
+
+This has its problems:
+
+1. The set of files you want in the project git repo may not be the same as the set of files you want synced across machines. For instance, I use a large software project that I compile from sources. I want to sync binaries across machines (it takes forever to compile!), but of course I don't want them commited into the project, not even as annexed files.
+2. Configuring remotes for every project is tedious. What if some remote changes url? what if I want to change the path of some of the git projects? Every time I add a new repo I need to configure all the 4 remotes. This can be scripted of course, but is not my ideal solution.
+
+What do you think about the submodules route I proposed? I don't like submodules very much, but in this case, I think it could become a good solution. In particular it would solve 1, 2 above and be able to merge conflicting changes on the nested repos.
+
+"""]]