1025_gitify_your_life.ogv

Time we start with the next talk

I welcome Richard Hartmann

He is involved in Debian since many years

and he became recently Debian Developer

and he will talk about gitify your life.

?, blogs, configs, data and backup. gitify everything

Richard Hartmann

Thank you. [applause]

Thank you for coming

expecially those who ? years attended all ?

Short thing about myself

As ? said I'm Richard Hartmann

In my day job I am backbone manager at Globalways

I'm involved in freenode and OFTC and...

should I speak louder?

I'm not...

test, test... good back there?

Can you turn up the volume a little bit?

test, test... ok, perfect.

Since about a week I've been a Debian Developer (yay)

[applause] and I'm the author of vcsh.

Raise of hands: who of you know what git is?

perfect

That's just as in ? perfect, we can skip it.

Let's move to the first tool, etckeeper.

Some of maybe most of this audience will have heard of it,

it's a tool to basicly store your /etc in pretty much every version control system you can think of

It's implemented in POSIX shell

it autocommits every thing in /etc basically at every opportunity

you may need to write excludes, for example

before your network config ?

but else, yeah, that's really cool

the autocommit

it hooks into most of the important or maybe even all of the important package management systems

so when you install your packages, even on SuSE or whatever

you can just have it commit automatically, which is very nice

You can obviously commit manually

if you for example change your X config

it supports as I said various backends

it's quite nice to recover from failures

for example ? used it to recover from saturday's power outages

because some servers lost stuff and with etckeeper you can just replay all the data which was...

rather nice.

Then there is bup.

bup is a backup tool based on the git pack file format

it's written in python

it's very very fast

and it's very space efficient.

The author of bup managed to reduce his own personal backup size

from 120 GiB to 45 GiB

just by migrating away from rsnapshot over to bup

which is quite good

I mean, it's almost or a little bit more than a third, so

very good

This happens because it has built-in deduplication

because obviously git pack files also have deduplication

You can restore every single mount point

or every single point in time

every single backup can be monted as FUSE filesystem or a ? filesystem

independently of each other

so you can even compare different versions of what you have in your backups

which again is very nice

the one thing which is a real downside for serious deployments

there is no way to get data out of your... archive or out of your backups

which again is a direct consequence of using git pack files

there is a branch which supports deleting old data

but this is not in mainline and it hasn't been in mainline for...

I think one or two years

so I'm not sure if it will ever happen but...

yeah

at least in theory it would exist.

Then for your websites, for your wikis, for your whatever there is ikiwiki.

ikiwiki is a wiki compiler,

as the name implies,

and it converts various different files into HTML files

it's written in Perl

it supports various backends

again most of the ones you can possibly think of

oh, I can even slow down, good

it's able to parse various markup languages, more on that on the next slide

there are several different ways to actually edit any kind of content within ikiwiki

it has templating support, it has CSS support

these are quite extensive, but they may be improved, but that's for another time

it acts as a wiki, as a CMS, as a blog, as a lot of different things

it automatically generates RSS and Atom feeds for every single page, for every subdirectory

so you can easily subscribe to topical content

if you are for example only interested in one part of a particular page

just subscribe to this part by RSS

and you don't have to check if there updates for it

which is very convenient to keep track of comments somewhere or something

It supports OpenID, which means you dont have to go through all the trouble of...

having a user database or doing very...

or doing a lot of antispam measures

because it turns out OpenID is relatively well...

suited for just...

stopping spam. For some reason, maybe they just

haven't picked it up yet, I don't know

but it's quite nice, because you don't have to do any actual work

and people can still edit your content, and you can track back changes at least to some extent

it supports various markup languages, the best ones, well, debatable, but in my opinion is Markdown

it supports WikiText, reStructuredText, Textile and HTML and there are ikiwiki specific extensions

for example normal wikilinks which are a lot more powerful than the normal linking style in MarkDown

which kind of sucks, but... whatever

it also supports directives, which basically tell ikiwiki to do special things with the page

for example you can tag your blog pages

or you can make...

generate pages which automatically pull in content from different other pages and stuff like this.

that's all done by directives.

How does it work?

You can edit webpages directly, if you want to, on the web

then you will have a rebuild of the content

but only the parts with changes

so if you... hello?

if you change only one single file it will only rebuild one single file

if you change for example the navigation it will rebuild everything because obviously...

it is used by everything.

If it has to generate pages automatically, for example the index pages or something

if you just create a new subdirectory, or if you have...

if you have commands which have to appear on your site

it will automatically generate those MarkDown files and commit them

or you put them in your souce directory and you just commit them and...

and have them part of your site, or you can autocommit them if you want.

That's possible as well.

You can obviously change... pull in changes in your local repository if you want to look at them

Common uses would be public wiki...

private notes, for just note keeping of your personal TODO list or whatever

having an actual blog, which a lot of people in this room probably do

that's, yeah, I mean a lot of people on Planet Debian have their blog on ikiwiki, for good reasons

and an actual CMS for company websites or stuff

which also tends to work quite well.

The three main ways to interact with ikiwiki are webbased text editing, which is quite useful for new users, but is quite boring, in my opinion,

there is also a WYSIWYG editor which is even more fancy for non-technical users

and there is just plain old CLI-based editing way:

just edit files and commit them back into repository pushes up and everything gets rebuilt automatically , which is...

in my opinion the best way to interact with ikiwiki, because

you are able to stay on the command line and simply push out your...

your stuff onto the web and you don'tactually have to leave the command line

which is pretty kinda neat.

There are also some more advanced use cases

as I said you can interface with the source files directly

you can maintain...

something is wrong

for example you can maintain your your wiki and your docs and your...

source code in one single directory

and it would simply...

and simply have parts of your subdirectory structure rendered.

for example git-annex does this

there is a doc directory, which is rendered to the website

but is also part of the normal source directory

which means that everybody who checks out a copy of the repository

will have the complete forum, bug reports, TODO lists

user comments,

everything on their local filesystem, without having to leave - again - their command line,

which doesn't break media, and so is just very convenient to have one single resource for everything regarding one single program.

And another nice thing is if you create different branches

for preview, staging areas you can have workflows where some people are just allowed to create ...

pages, other people then look over those pages and merge them back into master and then push them on the website

which basically allows you to...

to have content control or real publishing workflow, if you have a need to do this

Next stop: git-annex.

The beef.

It's basically a tool to manage files with git without checking those files into git

?

Yeah, what is git-annex?

It's based on git,

it maintains the metadata about files,

as in location, and file names and everything, in your git repository

but it doesn't actually maintain the file content within the git repository

more on that later

this saves a lot of time and space.

You still able to use any git-annex repository as a normal git repository

which ? means you're even able to have a mix of...

for example, say, all your ? files

should be maintained by normal git,

and then you have all the merging which git does for you and everything

and then you have for example your photographs,

or your videos for web publishing

which are maintained in the annex

which means you don't have to have a copy of those files in each and every single location

A very nice thing about git-annex is that it's written with very low bandwidth and flaky connections in mind

quite a lot of you will know that Joey lives basically in the middle of nowhere

which is a great thing to be forced to write really efficient code

which doesn't use a lot of data, and that shows:

it's really quick

and even if you had a really really bad connection

in backwaters or whatever...

during holidays or during normal living

it's still able to transfer the data which you need to transfer,

it's very very nice

There are various workflows: we'll see four of them in a few minutes

So. It's written in Haskell, so it's probably strongly typed and nobody can write patches for it

it uses rsync to actually transfer the data,

which means it doesn't try to reinvent any wheels

it's really just based on top of established and well know and well debugged programs

In indirect mode, which in my personal opinion is the better mode,

what it does is

it moves the actual files into a different location, namely .git/annex/objects

it then makes those files read only, so you cannot event accidentally delete those files

even if you rm -f them, it will still tell you no, I can't delete them,

which is very secure

may be incovenient, but you can work on this

it replaces those files with symlinks of the same name, and those just point at the object

and if there is an object behind this symlink or not...

that basically returns whether you are able on this particular machine, or in this particular repository

but you will definitely have the informations about the name of the file, the theorethical location of the file...

the hash of the file will be in every single repository

There is also a direct mode

initially mainly written for windows and Mac OS X

because Windows just doesn't support symlinks properly

and OS X was supporting symlinks,

apparently has lots of developers who think it is a great idea to follow symlinks...

and display the actual target of the symlink instead of the symlink

so you have cryptic filenames which are very hard to deal with

obviously people who are used to GUI tools which then only display really really cryptic names ?

so there is direct mode which doesn't do the symlink stuff

it basically rewrites the files on the fly

git still thinks it would be managing symlinks, but...

git-annex just pulls them up from under git, and pushes in the actual content.

You keep on nodding, so... I'm probably doing good

and if you want you can always delete old data, or you can keep it...

or you can just... for example what I'm doing:

you can have one or two machines which slurp up all your data...

and have an everlasting archive of everything which you've ever put into your annexes...

and other machines, for example laptops with smaller SSDs

those just have the data which you are actually interested in at the moment

How does this work in the background?

Each repository has a UUID

It also has a name, which makes it easier for you to actually interact with the repository...

but in the background it's just the UUID for obvious reasons...

because it just makes ? and synchronization easy, period

It's also tracking informations in a special branch called git-annex

this branch means that all...

this branch ? every single repository has full and complete informations...

about all files, about the locations of all files, about the last status of those files...

if those files have been added to some repository

or they have been deleted,

or if they are being over there forever

so in every single repository you can just lookup the status of this file or of all files in all of your repositories

which is, yeah, convenient

The tracking information is very simple

and it's designed to be merged very...

it's a little bit more complicated than applying union merge,

but basically what it does is it adds a timestamp

and tells if the file is there or not and it has the UUID of the repository

and from this informations, along with the timestamps you can simply reproduce...

the whole lifecycle of your files through your whole cloud of git-annex repositories

in this one particular annex.

One really nice which you can do is...

if you are on the command line, which again in my opinion is the better mode...

you can simply run git-annex sync

which basically does a commit...

oh, it does a git-annex add, then it does a commit,

then it merges from the other repositories

into your own master, into your own git-annex branch

then it merges the log files

that's where the git-annex branch comes in

and then it pushes to all other known repositories

which is basically a one-shot command to syncronize all the metadata about all the files with all the other repositories

and it takes no time at all

given a network connection

Data integrity is something which is very important for...

yeah, for all of the tools, but git-annex was really designed with data integrity in mind

by default it uses a SHA-2 256 with file extension...

to store the objects, so it renames the file to its own shasum

which allows you to always verify the data even without git-annex

you are able to say by means of globbing...

which files, or which directory, or which types of files should have how many copies in different repositories

so for example what I do:

all my raw files, all theraw photographs are in at least three different locations,

all the JPEGs are only in two, because JPEGs can be regenerated

raws can not.

All remotes and all special remotes can always be verified

with special remotes this may take quite some bandwidth

with actual normal git-annex remotes you run the verification locally

and just report back the results with obviously saves a lot of bandwidth and transfer time

verification obviously takes the amount of requires copies into account

so if you would have to have 3 different copies

and your whole repository cloud only has 2, it will complain

it will tell you "yes, checksum is great, but you don't have enough copies, please do something about it".

and even if you ? right now, delete all copies from git annex

you would still be able to get all your data out of git annex

because what it boils down to, in indirect mode, it's just symlinks to other objects

these objects have their own checksum as their file name

so you'll even be able to verify, without git-annex,

just by means of a little bit of shell scripting,

that all your files are correct,

that you don't have any bit flips or anything on your local disk.

direct mode doesn't really need a recovery ?, because...

the actual file is just in place of the symlink

but on the other hand you won't be...

you still need to look at the git-annex branch to determine the actual checksums

which you wouldn't have to do with the indirect mode.

There are a lot of special remotes. And what are special remotes?

these are able to store data in non git-annex remotes

because, let's face it, on most servers, or most servers where you could store data

you aren't actually able to get a shell and execute commands

you can just push data to it, you can receive data

but you cannot actually execute anything on this computer.

That's what special remotes are for.

All special remotes support encrypted data storage

so you just gpg encrypt your data and then send it off

which means that the remotes can only see the file names

but they cannot see anything else about the contents of your files

obviously you don't want to trust amazon or anyone to store your plain text data

that would just be stupid

There is a hook system, which allows you to write a lot of new special remotes

you'll see a list of... quite an extensive list of stuff in a second

Normal, built-in, special remotes which are supported by haskell out of the box

by git-annex out of the box

and actually implemented in haskell

are Amazon Glacier, Amazion S3, bup, directory — a normal directory on your system

rsync, webdav, http or ftp and the hook system

there is a guy who brought most of those

we can support archive.org, IMAP, box.com, Google Drive... you can read them yourself, I mean...

but those are quite a lot of different special remotes, if you...

already have storage on any of those services, just start pushing encrypted data to it if you want, and you're basically done.

There is an ongoing project called the git-annex assistant

last year, and I think this year it just ended, didn't it?

so, pretty much exactly one year ago Joey has started to to raise funds

by means of a kickstarter to just focus on writing git-annex assistant for a few months

he got so much that he could do it for a whole year

and he's just restarted the whole thing with his own fundraising campaign without kickstarter and he got another full year

yeah... are you still accepting funds?

ok, so, if you use it at least consider donating

because honesty you can't write patches for it anyway, because it's in haskell, so...

that's... the other means of actually contributing

git-annex boils down to be a daemon, which runs in the background

and keeps track of all of your files, of newly added files

and then starts transferring those files, if configured to do so

it starts transferring files to other people or to other repositories

this is all managed by means of a web gui

which in turns means that it's really, well, not easy, but easier to port to for example windows or android

which both work, to some extent

not fully, but they are useful, or useable, more or less

at least on android it's really quite good, I couldn't test it on windows, because...

and it also makes it accessible for non technical users

so for example if you want to share some of your photographs with your parents

or with friends, or if you want to share, I don't know, videos with other people

you just put them into one of those repositories

and even those non-technical people just magically see stuff appear in their own repository

and can just pull the data if they want to

or if you configured it to do so, it would it would even transfer all the data automatically

which is... it's ?

It supports content notifications, but not content transfer

by means of xmpp or jabber

which used to work quite well with google talk, I think it's not...

oh, it still works, ok

at least at the moment, we'll see when they just ? google ? with google+, but...

at least at the moment it still works, if you have a google account you can simply transfer all your data

you can transfer the metadata about your data, you cannot actually transfer the files through jabber

but that's probably something which will happen within the next year

there are quite ? rulesets for content distribution

so for example I can show you...

you can say "put all raw files into this archive, and all jpegs on my laptop", or whatever

or "if I still have more than 500 GB free on this please put data in

and as soon as only have 20 left stop putting data into this one repository"

which obviously is quite convenient

as I said there is a windows port, and now on to usecases.

First usecase: the archivist.

What the archivist does is: basically he just collects data

either to ? or just to collect

and if you have this usecase what you probably want to do, you want to have offline disks

to store at your mom's, or to put into a drawer

or just you don't have enough sata ports in your computer because you just have so much data

so, what you can do is you can just push this data to either connected machines or to disconnected drives...

or to some webservice, and just store data

but normally you would have the problem of keeping track of where your data lives

if it's still ok, if it's still there, everything.

With git-annex you can automate all this administrative side of archiving your stuff.

Even if you only have one of those disks, if they're a proper remote...

you'll have full informations about all the data in your annex cloud up to this point

so even if you only pull out one random disk you still have informations on all the other disks on this one disk

which obviously is a nice thing.

Media consumption.

Let's say you pull a video of this talk, or you get some slides...

maybe also from this talk, you can get some podcasts...

and git-annex has become a native podcatcher quite recently, I thing two or three weeks ago

which means you don't even have a separate podcatcher

you just tell git-annex "this is all of my rss feeds" and it will just pull in all the content,

Then you can synchronize all this data for example to your cellphone, or your tablet, or whatever

consume the data on any of your devices, even if you have 10 copies of this particular podcast

because you didn't get around to listen to it on your computer...

and you didn't get around to listen to it on your cellphone

but then on your tablet you did listen to it

you have three copies of this file which you don't need anymore...

because you have listened to the content and you don't care about the content anymore

what you do is you drop this content on one random repository

and this information that you have dropped the actual content,

not the metadata about the content, but the actual content, you don't need the content anymore...

will slowly propagate to all of the annexes and if they have the data they will also drop the data

so you don't have to really care about keeping track of those things

you can simply have this message propagate

do you want to comment? can someone give Joey a microphone?

Just a minor correction

it doesn't propagate that you've dropped the content

but you can move it around in ways that have exactly the effect you described

? get the wrong idea that if you accidentally remove one thing it will vanish from everything ?

but if you deliberately drop the content and tell the annex...

no. that's not how it works.

I want to talk about it later, but it's...

you looked at the slides, but...

sorry, ?

He watches for everything which is ?

Next thing, if you are on the road, and one usecase which is probably quite common: taking pictures while you are on the road ?

You take your pictures, you save them to your annex

where you are able to store them back to your server or wherever

if you want to, and even if for example one disk gets ?

and you lose part of your content,

you'll still at least be able to have an overview of what content used to be in your annex

and if you then pull out your old SD card and see "oh, that photo is still there" you can simply reimport it and it will magically reappear.

What it also does is:

if you have a very tiny computer with you

you can, as soon as you are at an internet cafe, just sync up with your server or your storage, whatever

and push out the data to your remotes

which then means you'll have two or three or five copies of the data

and git-annex keeps track of what is where for you

so you don't have to worry about copying stuff around.

And then there is one personal usecase, for photographs

I have a very specific way of organizing my photographs

my wife disagrees violently

she likes to do her photo storage in a completely different way

she doesn't care about the raw files

and she doesn't care about all the documentation pictures of signposts or whatever which I just took to remember which cities we went through

so what she can do is she can simply delete the actual files or ? the symlink of this file

and it will disappear from her own annex

she can then commit all this

normally if she would sync back the data I would also have the same layout, which I don't want

expecially since she tends to rename everything a lot

but what I did, I set up a rebasing branch on top of my normal git-annex repository

so what she gets is: she has her own view of the whole data

or the part she cares about

and when I add new content

she will see the new content, she will rearrange the content however she pleases

but as it's a rebasing branch

all her changes will always be replayed on top of master

so she has her own view, and I don't even notice her own view

but even if she uses one of the other computers she would have the same view which she herself has

so basically she has her own view all of the data

This is very convenient to keep the peace at home.

Next topic: vcsh.

Most of you here probably have some sort of system...

where they have one subversion or cvs or whatever repository

and they have it somewhere in their home directory

you symlink into various places in your home directory, and it kind of keeps working so you don't throw it away, but...

to be honest it sucks. Here is why.

Or, here's why in a second.

vcsh is implemented in POSIX, which is very very portable

it's based on git, but it's not directly git

The one thing which git is not able to do is maintain several different working copies into one dicrrectory

which is a safety feature, more on that later

but this really sucks if you want to maintain your mplayer, your shell, your whatever configuration

in your home directory, which is the obvious and only real place where it makes sense to put your configuration

you don't want to put it into dot-dot-files and then symlink back

you want to have it in your home directory as actual files.

So, vcsh uses fake bare git repositories

again, more on that on the next slide

and it's basically a wrapper around git

which makes git do stuff which it normally wouldn't do

and it has a quite extensible and useful hook system which ? will care about

Whith a normal git repository you have two really defining variables within git

you have the work tree

which is where your actual files live

and you have the $GIT_DIR, where the actual data lives

normaly in a normal checkout you just have your directory and .git under this

If you have a bare repository you obviously don't have an actual checkout of your data

you have just all the objects and the configuration stuff

so that's what a bare repository boils down to being

A fake bare git repository on the other hand has both

it has a $GIT_WORK_TREE and it has a $GIT_DIR

but those are detached from each other

they don't have to be closely tied together

and also sets core.bare = false, to actually tell git that "yes, this is a real setup, but..."

"yes, you still have a work tree, even thought you don't really expect it"

"to have one, you still have a work tree".

By default vcsh puts your work tree into home

and your git dir into...

it's based on .config/vcsh/repo.d and then the name of the repository

which just puts it away and out the way of you actually seeing stuff

but it follows the cross desktop specifications so if you move stuff around it will also follow

Fake bare repositories are really...

are messy to setup, and it's very easy to get them wrong

that is also the reason why git normally disallows this kind of stuff

because all of a sudden you have a lot of...

context-dependency on when you do what

just immagine you set git workdir...

$GIT_WORK_DIR, sorry

and run random commands like git add, that's...

kind of ok, if you git reset --hard you'll probably not be to happy

you checkout the current version that's also quite bad

and if you clean -f, yeah, you just throw the home directory

congratulations

So, it's really risky to run with these variables set

which is why I wrote vcsh to wrap around git

to hide all this complexity and do quite some sanity checks to make sure everything's set up correctly

again it allows you to have several repositories and it also manages really the complete lifecycle of all your repositories

it's very easy to just create a new repository, you just init, just with git

you add stuff, you commit it, and you define a remote and start pushing to this remote

simple

This looks like git because it's very closely tight to git

and it uses a lot of the power or of the syntax of git, for obvious reasons

because... it's closely tight to git

you can simply clone as you would with git

you can simply show your files as you would with git

you can rename the repository, which git can't do, but you don't have to

you can show the status of all your files

or just of one of your repositories

or of all repositories

you can pull in all your repositories at once, you can push all of your repositories at once

with one single command

so, if you are on the road, or you just want to sync up a new machine it's really quick, it's really easy

There are three modes of dealing with your repositories

default mode is the quickest to type

you just say vcsh zsh commit whatever or any random git command

but you cannot really run gitk

you can do this by using the run mode, which is the second mode

we simply ? here run is missing and here git is missing

so you say simply vcsh run zsh git commit whatever

and this is exactly the same command, it's literally the same comand once it arrives at the shell level, so to speak

here you can also run gitk, because...

with this, you set up the whole environment for one single command to run with this context

of the changed environment variables

or you could even enter the repository, then you set all the variables

and then you can just use normal git commands as you would normally

this is the most powerful mode,

but it's also the most likely to hurt you if you don't know what you're doing

so I don't recommend working ? down this way.

You should have your shell display prompt information about being in a vcsh repository or not

simply because else you may forget that you entered something

and then if you run those commands, there will be pain

At once the usecases, which will be possible quite soon

we can just combine vcsh with git-annex to manage everything which is not configuration files in your own home directory

? basically two programs to sync everything about all of your home directory

without having to do any extra work

you can also use it to do really wierd stuff

for example you can backup a .git of a different repository with the help of vcsh

so you can just go in, change objects or anything, break stuff and just replay whatever you're doing

just to try and see how it breaks in interesting ways.

You can just backup a working copy which is maintained by a different reopository or a different system

you can even put a whole repository, including the .git,

into a different git file

or you can even put other VCSs like subversion or something into git, if you want to.

Then there is mr.

mr ties all those...

hopefully by now you have about twenty new repositories

because you have configuration, you have ikiwiki, you have everything

so now you need something to syncronize all those repositories

because doing it by hand is just a lot of work

mr supports push, pull, commit operations for all the major known version control systems

allowing you to have one single interface to operate on all your systems

It's quite trivial to write support for new systems

I think it took me about two hours to support vcsh natively

so, that's really quick

If you want to try, the stuff which I told you about...

in the links later there will be the possibility to just clone a subrepository for vcsh

which will then put up a suggested mr directory layout

and you can just work from there

This is the... alright, it's my suggested layout

which basically...

you just include everything in config.d you maintain...

your available.d, by means of vcsh, so you simply sync around all your content between all the different computers

and then you simply soft link from available to the actual config

which is basically what apache does with sites.enabled and sites.available

or modules.available and modules.enabled

which is really really powerful

Last thing is not git based, but zsh.

It's a really powerful shell, you should consider using it

it has very good tab complection for all the tools listed here, more than bash

it has a right prompt, which will automatically disappear if it needs to

which is very convenient to display not important but still useful information

and it will automatically, if you tell it to, tell you about you being in a git repository or subversion repository or whatever

by means of vcs.info

which also means you'll be told that at the moment you are in a vcsh repository

and you may kill your stuff if you do things wrong

it can mimic all the major shells

and there's just too many reasons to list

So... final pitch

This is true: I've tried it earlier, I can demo it, I still have five minutes left

it takes me less than five minutes to syncronize my complete, whole, digital life while on the road

so if I'm at the airport and just want to update all my stuff,and push out all my stuff...

it'll take a few minutes, but then I can hop on the airplane...

and I'll know everything is fine, everything is up-to-date on my local machine

on my laptop machine, I can continue working, and have a backup on my remote systems

These are the websites

The slides will be linked from penta, so you are more than welcome to look at these links later

There are previous talks, which you can also look at, if you want to

and that's pretty much it

and if you have any more questions afterwards either catch me...

or there is an IRC channel, and there is a mailing list

ok, we can take a few questions, we have still a few minutes

then if there are more questions ask Ritchie afterwards

And while we are doing this just look here, because that's a complete sync of everything I have

Just to make sure I understood this correctly,

with git-annex the point is that the data is stored dispersed over different local destinations, so to speak

but the metadata ? exists, ? complete git history

so git is able to tell me, "well, this version at that destination was changed at that time and so on and so on"

did I get this right or...

git will be able to tell you about changes...

ok, I don't have internet, sorry

git will be able to tell you about changes in the filenames, or directory structure

git-annex will be able to tell you about changes in the actual file content

or in moving around the files

but as one single unit, more or less, then yes...

the answer is yes, but not quite, but yes

yes, but ? all the things you asked about are in git, you know the previous location, all that stuff

but in a separate branch which you should use git-annex to access, but you can do it by hand if you want to

I'm not familiar with tracking branches,

yet you mention that the workflow for your wife has a different view of the data than you

with that workflow is it possible for your wife to upload photos that you will have in your view as well, or is it a oneway street?

minor correction: tracking branches track a different repository,

what I meant was rebasing branches, which rebase on top of a different branch

which basically just keeps the patches always on top of the branch, no matter where the head moves to

if she wanted to do that she would need to simply git checkout master

do whatever she wanted to do, and then git checkout her own branch, and then she's...

she is able to, but she would need to change into the master branch and then back

microphone

she never pushes her private branch? it always lives on her own machine?

no, she does push it, but I don't display this view of the data

because else she wouldn't be able to syncronize this view between different computers

I seem to have internet now, so let's just let this run in the background

any more questions?

no more questions?

than we...

? more minutes for questions?

ok, so thanks to Richard Hartmann, we will continue...