automating git-annex relationships

[martin f krafft]

also sprach Joey Hess <joey at 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 at 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://joey@git.kitenet.net/srv/git/downloads
>         cd downloads
>         git remote add website ssh://joey@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.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1107 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20140909/8604b868/attachment.sig>