Added a comment

This commit is contained in:
https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48 2013-11-22 18:44:35 +00:00 committed by admin
parent 07f47e1558
commit 29ba93ba52

View file

@ -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.
"""]]