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
