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...