also sprach Joey Hess <j...@kitenet.net> [2014-09-09 17:20 +0200]: > Note that the part after the -- here is just a description, and can be > any free-form text.
I was going to suggest that there could be another field added to the protocol, but… > Recent versions of git-annex have a hidden feature that's used by the > webapp. The url of an existing git remote can be stored: > > git annex initremote albatross type=git > location=madduck@albatross:~/family/veronika/photos … you preempted that! > And then the same git remote can be set up elsewhere, using that stored > url: > > git annex enableremote albatross Unfortunately, the requirement for the remote to already exist kinda makes it hard to use, for two reasons: 1. The location depends on both sides of the equation, there's not always a canonical one. 2. I'd want to set up the special remote once locally, and then use it elsewhere. If I have to set it up elsewhere, I might just as well add the remote directly… % git annex initremote one type=git location=`pwd` (merging origin/git-annex into git-annex...) (Recording state in git...) initremote one git-annex: could not find existing git remote with specified location > I use mr to set up remotes. > > [lib/downloads] > checkout = > git clone ssh://j...@git.kitenet.net/srv/git/downloads > cd downloads > git remote add website > ssh://j...@git.kitenet.net/srv/web/downloads.kitenet.net/.git Yeah, like Adam. With the use-case of two machines that are more or less identical, as well as plenty of SSH hosts out there, which only get a subset of the repos, I would have to keep a list of remotes centrally maintained, and possibly a different set for each host as remote URI depends on the relationship, not a single host. Maybe Git rewrite rules can help here, as Adam suggests, but it just gets messy. The reason I am worrying about this is because rather than having a single git-annex repo for everything in $HOME, I'd rather have a different repo for each project I am involved with, and that's several dozens, so there's a lot of repetitive work ahead, and much redundancy to be created. The reason for having separate annexes is quite simply that some of them are shared with others, while most are not. So yes, I could have a single annex for $HOME and a few annexes for sharing, and use views (tags) to select which files appear where. But views don't (yet) update automatically¹ and there are strict limitations on filenames², which make views a nice query tool, but not really a tool for persistent use. ¹) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743820 ²) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743794 I would love to have real tagging because I have so many files that belong to more than one project… :/ </mind mode="wander"> -- @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ "i believe that the moment is near when by a procedure of active paranoiac thought, it will be possible to systematise confusion and contribute to the total discrediting of the world of reality." -- salvador dali spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
_______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home