 Okay, so there should be a conversation, or kind of yelling at each other, so everyone hears everyone else. Just quick show of hands, who thinks they're really familiar with it? Who thinks they're somewhat familiar with it? And who thinks they are not really familiar with it at all? Okay, that's fine. Daniel, if you want to stand here, the door is unlocked. I'll come back. There's also a door here, I think. That's locked. So, most people know this a little bit about you, that's good. What are you interested in? Should we talk about non-code reasons of it? That's usually the thing which gets most people here. So, do you want to just talk about best practice of using it for non-code reasons? Show of hands. Okay. What about using it for non-code reasons, for managing your configuration, your photographs, your stuff? What about the people who don't raise their hands? Just here to listen? It's okay, as long as it's not about gifts. So, as I was saying, this is a subversion block. So okay, who of you is using it for non-code reasons? And who of you wants to share any best practices? So, this is not just me talking all the time. Or are you all hiding? If I make you raise your hands again, I'll send you off. So, no one wants to speak up yet. Anything which you like about it or don't like about it, which you want to talk about. Sorry. Anything which you like or do not like about it, which you want to talk about. No one will find you if you speak up. I have no issue with talking for an hour and making a few stupid jokes. Yeah, sure. Is there any problem to talk about using gift for packaging? Using gift for packaging? We could, but the book is quite useless because there will be a gift build package. I think it's a book. It's quite useless to do this now because there is actually, yeah, a gift build package skill scare and gift build package pop in the same room. So, there's two more hours of building packages with gift. It's great. I can only recommend it. It works very well. I do nothing else. It makes your workflow really, really simple and easy. Yeah, but let's show this later. Still no one speaking up? I can say what to say. Yeah, sure. Go ahead. I'll keep your maintaining the server. Can you just move here or here because you keep blocking the door? If you're maintaining a server with a couple of other people, you're missing out if you're not using a DC keeper, which can be used as a button. Then you... Powder, yeah. Also, maybe set it up. We don't buy it, promise. If you're maintaining a server with a couple of other people, you're kind of missing out if you're not using, for example, an ITC keeper that uses gift, can use gift as one of its backends because then you can see what the other systems have been mucking about in the ITC configurations. And it has saved my cut more times than I care to acknowledge. The ITC keep is also quite nice for having centralized backups of your servers. Because obviously you have proper backups, which you should have, but hopefully most of us do. Yet when you just need to really find the same machine or just want to clone it relatively quickly without having a full puppet or whatever set up, it's quite easy to just clone the configuration to two-year central side, just set up a new machine, clone it back there, change a few settings, bring it up, and basically clone the machine within minutes. Quite useful. Obviously you need to copy all the data. Sure. But else, yes, ITC keep is very, very handy. Sorry, ITC keep is very, very handy when you... not only for fixing things, but also for re-employing if you don't have a large set up where you are an automated system for deployment. Anyone else? You were first. We are using Solstack and Reclass for configuring machines, and we have set up a GitLab server, and we are a couple of people, and it's really... it makes fun doing the... and all that stuff using Git. So I can really recommend Git and GitLab as well. That's a great move. Yeah. Having GitLab as a backup for your configuration makes it easier for non-technical people to also have a look. So if management comes along and you can tell, okay, this shiny thing here, just click around and you'll see what we are doing. They may not understand it, but they may appreciate it. And also first level, people can easily... Just move over here. Come in. Move over here. This way you get fresh air. Yes, it's still just nice and long. Okay, is there a door on that way? Yes, but it's still up. So just come here. Okay. All right, we'll see if there's a door on that way. Okay. The next guy who raised the table was... No, you were the first. The one behind you. Yep. Can you check in here? I think it was there. Wasn't it? Yeah, probably. I do have to raise that things, not Solstack get kept in Git. I hope every single one of them has a log of things that you do during your day, keep a record of things you've learned and so on. I find that keeping that in Git is a really handy way to be able to grep for things with the stuff very quickly without needing additional and unusual tools. But what exactly do you mean by keeping a log just having a text file? I happen to use a text file per day. Okay. I carry actions across. I keep a log of what I'm doing. I keep a log of the conversations that I've been having, and it just provides a really convenient single place and then all of the Git tools for looking through code bases, organizing code bases and so on give you an advantage just in your daily records. Reusing the tools which are already implemented in Git as a regular client, because obviously you can leverage a lot of tools and a lot of workflows which have already been polished very, very, which have already been, yes, sorry, which have already been polished to a very high level, which means you are able to really, yeah, use quite as much workflows for areas where you normally wouldn't have any tools which you could use. Yeah. Another thing I'm going to, I'm planning to use, I'm not completely using it right now, is deploying Ansible configuration with Git. So, I mean, the configuration is managed by Git, and the Git hook can then execute Ansible stuff for those who are not familiar with Ansible. It's mostly like chat from its, it's a non-move tool, a configuration deployment tool, and a Git hook could then be used to execute change management, centralized, yeah, but also where the actual code is. Any more? Yeah. So, I'm abusing this a little bit. That's good. I brought a little bit of context. I brought a performance benchmark or performance dashboard for a rather large project with Haskell Compiler. So, I have a build log which builds every single Git commit that comes in and produces a log file. It's just the build log where all the data is somehow passed later. So, I'm storing these build logs, and I need to move them to the place where, back to the website. So, I'm abusing GitHub, those three hostings or whatnot. I'm putting all the logs into Git repository with hash.text as the filename. And then I'm processing that on the website to use a static page that has nice graphs. Maybe I'll, I think, talk about that too. And it turned out that, because the build logs are rather large already, a few megabytes, some of them, and doing that for each Git commit and a very active project and historically, I get a Git repository that happens to have a check-out size of 16 gigabytes. That was kind of annoying. So, it was first annoying on the server side where I was reading the file. So, what it bear was, I'm not actually checking out the repository, rather having a bear repository from this other, just the .git directory. And I changed my build tool to read the files directly from the bear repository. Basically, using Git show filename that works even if you don't have it checked out. And it's even the case that the build system on the server side that takes the logs and produces the HTML output is, well, there's some kind of dependency tracking make like logic inside, it doesn't want to make directly, but something a bit more sophisticated where you can customize what it thinks, like the checks it has to do to see something updated. So, it's actually using the Git commit to see if maybe I did a re-rand the logs. So, you can hook into Git to, if you're doing a kind of programming to get a better idea about changes and when things exactly changed, then high stamps, because they might be off because you just reinstalled everything. So, on the client side, I solved the problem with the size using a very obscure new feature of Git, not very new, but it's sparse checkout. So, it allows you to tell Git, well, I want to have a checkout of this repository, but please don't bother with these files. And I tell it to please don't bother with all files. So, this means I don't have any of the files to check out. I can still add files, and if I run them, Git to check out, it'll make them disappear. So, it's like a black hole where you can throw files in and they end up in the checkout zone and it all works very well. So, now it's only 600 megabytes because Git is good at compressing across files and the build logs are, of course, very repetitive and compress very well. So, that's how I solved the problem. Yeah, I guess people told, I guess I should have used some kind of hashing directory name scheme. I don't just put the hash in the file name or rather the first two digits as a directory name. So, yeah, that's a good abuse. It kind of works. Have you tried to replace the last log with the newest log all the time you commit? So, you just have one log in one commit and then use the Git history to browse through. Well, I still want to index into the thing. The last thing is now I can, for any Git commit of the project, I can just go to GitHub and produce a URL into GitHub that gives me that file. So, I think it's also a way of posting all the Git logs for people. You can really browse it there. More than a thousand files. I'm not going to show you these, but you can still get to an individual file because they are all in the latest version. I guess that feature would be most interesting. And it wouldn't gain much because it's not like it's copying each file for the new commits. Well, you can use the diff function of your Git to see what is different. In the build log? Yeah, in the build logs. It must have changed. I actually wrote that down as far as using it that way. That's really interesting. Yeah, sure. So, I actually want to shift focus to something which is not so much about versioning, but more about controlled data exchange. What's the scenario? So, in my corporate environment, I have separated networks for production and development testing environment, and there are strict regulations not to establish any kind of automated connection between both. So, of course, that's not that bad in the first place, but there are situations where you want to share data somehow. For example, you do an analysis in the production, take your notes, and want to transfer it to a development network to make a close analysis, then document your solution there to try in the production environment, maybe such thing. So, of course, you can always put it all in USB stick, and then you have this floppy disk feeling from 20 years ago you never know what is the current version and where is the most actual current version to continue from. But one solution is to have a git repository on a dedicated USB stick. You can even encrypt it if you have some paranoia, and then you can have some kind of controlled data exchange via USB stick with a git on top of it. With a small script wrapper, you can even automate it that you get the shell prompt not before this USB stick is properly unmounted, and then you don't run into all those device issues there. I found it quite convenient just to work around such regulations, and the point is with git, I can always argument that well, it's a controlled data exchange. There are not nasty things going on, because I can always control it via the history that bad things are injected into the production or something like that. I think you said something about encryption as well. Well, it's encrypted. Well, you can encrypt a USB stick, but you can always with some paranoia, you can also sign your change sets if you like. It would be an extension. I personally don't do this. Well, just to pick up the encryption part, I know you can say about git, but in the past with git, what you could do, you could encrypt a plaintext local storage and encrypt the backend with clean smudge filters which basically are scripts which run arbitrary code on everything you put into git or you get out of it, which allows you to just hook into a GBG or whatever to have plaintext in your local checkout, but everything on the server side or everything in the bear repositories is encrypted, or even other non-bear repositories as long as you don't have the key. There is git gcrypt in the meantime, which kind of does away with most of the hackery. So if you have any use cases where you would want to use git, but store it in non-trusted environments, I suggest you look at git gcrypt. That's quite useful sometimes. Sure, go ahead. I'd actually like to go ask a question. It goes like this. If you have ever used git to revision control some software you've been working on, put your hand up. If you have never no, keep it up. If you've never made a release of that software, put your hand down. Never. Or if you've never made a release using, so you've got git, you've got software in git, if you've never released that software, you can put your hand up. If you've never tagged that release, put your hand down. If you've never used an annotated tag to tag that release, put your hand down. And if you've never signed that annotated tag, put your hand down. Everyone with your hands up, thank you very much. We're thinking about best practices. Git has the facility when you tag something to not just make another breath of the point to that commit, but you can include metadata about that commit by annotating your tag. You should do that. And you should also then sign it. I actually do also do that for automatic commits when I have some production scripts for where I actually have, well not also the release management in the git repository, where I actually automatically commit everything and have the annotated actually annotate everything as okay, I build that and that because since the deployment is controlled by input data with a list I actually have it everything in the list, I build it then and then and did it for that customer. It's quite useful. Yeah, just don't forget to push the tags. Yeah, well yeah. Yeah, particularly what I was trying to get at is that tracing where software has come from becomes much, much easier when you can find cryptographically verifiable points to trace from. And one of the big things that we do at work is we try to do completely reproducible system builds using driven from git. So if we can start from a signed annotated tag of a commit of a set of definitions that point at char sums of things in other repositories to build and so on we can trace that all the way through and people who bother to put signatures on their software releases make our lives much easier. That's actually a nice point between this topic of the one of just before when because if you get used to signing your tags always you can also start sharing sharing information much more easily or much more easily. For example when I had some collaboration with packaging a package oh sorry what I just did was I just signed the tag, uploaded it and told him okay that's the tag as it was signed with my GTGP he knew he could trust that exact point in time and just go from there and then commit back. So this makes exchange a lot easier something which I have not done for VCSA check but I still want to do is to basically introduce an option where you're only allowed to check out in or to change into signed tags so you are not allowed to load any arbitrary points in your revision history you're only allowed to jump to signed tags within this history which would make it relatively simple to have automated tools which for example change your local configuration or do some deployment stuff or what have you without needing to manually check that this is okay and without just assuming that everything is fine and nothing bad will happen because you're just trusting your own GTGP if you have a list of keys which you trust and only deploy or load or whatever exactly those tags and this is basically what you're doing as well the automation behind it does not get easier as such but it's actually the case that only then you are really allowed from the security point of view to even use automation behind this point it provides a trust mechanism so if you use Git for deployments please please please with sugar on top use signed tags that go from there and disregard everything else because this gives you the security of someone I trust said this version is okay in addition because Git is underlying a content address a signed tag is a really convenient point to check that no one has tampered with your source code yes because you can verify the signature on the tag object that has the char one of the commit object you can verify the commit object and you can keep chasing it down just like we do with the signature on the releases file allowing us to verify all the way down to individual content in depth right if you've ever restored a Git repo from backup or if you've ever had to run GitFusk signed tags again give you that added level of confidence to be completely fair char one may not be the best choice even at the point where Git was intended or when it was invented char one was the best choice especially when Linus said it's not a secure mechanism but on the other hand he claimed that if he ever loses it with this repository you can just grab from wherever because there should be something else which we could migrate to in the immediate future but for now one would hope that the Git authors are considering other mechanisms of caching right now I kind of assume they just wait for char three to really be released and not publish but we'll see anyone else I want to add that there is a you can sign your comments for some time frankly I don't really know what would be the use case for it Linus again he said that doesn't make sense to sign comments because when you have signed tags that's just enough and I was for some time I was signing every comment that I was doing maybe one month ago he realized that probably doesn't make sense it does make sense I don't know but later on if you want to reach respect I have a thousand commits between those points and you could trust some of them and some of them maybe not but the problem is that for example when somebody rebases your patches you will lose signatures and in that case somebody may think that somebody tampered with your comments and that's not from you anymore and also there is a huge discussion about if anyone should ever rebase for any reason at all even if we don't get into that but even if you share a pic I mean well it's basically yeah but then someone else needs to resign that comment because someone else has to say I trust that whatever I did was correct it doesn't matter if they trusted based on they did it themselves or they imported from a trusted source now that they changed it they are the ones responsible for having trust and I see one huge difference between tags and commits which you can sign if you were to tag everything commit to sign it tags would lose a lot of their use because all of a sudden everything is tagged the tag means this is an interesting point in time at this point something happened which other people might look at commits are just way more not to say maybe at some point some safe commit at this point might be if cherry pic would become a security hazard in another right you don't want to sign off on that change right so yeah from your point of view someone who looks after gate repositories from the other end so the objects that are in them one advantage of signs commits is that there is exactly 50% of the objects in the repositories because a tag is an object if you sign it it's an annotated tag it's an additional object in the repository so commit signatures allow you to avoid that so if you're handing code to someone else and you want to be able to assert this is the change assigned commit is a cheaper way in terms of get objects to do that on the other hand there's nothing to stop you creating a tag if you want to and there's nothing to say that tag objects have to be pointed to by refs in refs tags I abuse the refs namespace quite heavily in various things that I do so I wrote a git server because I didn't like the fact that all the other git servers don't have their config in git and that git alike was horrible to my eyes and one of the first things that I did was work out how I would keep repository configuration in repositories without upsetting people who clone the repositories and so I actually end up with a namespace under refs that is for the git server so refs gitano the moment there's refs gitano config it's only one ref but that's managed by the git server and in fact when you reconfigure repositories and do things to your projects within a gitano server where on the server side makes commits to that ref in your name so you can trace configuration changes when you make configuration changes to the whole server there's actually an administration repository that normal pubs don't have access to that it keeps a git history of everything that's going on with the configuration of the server that means that the content of the git repository the admin repository is in fact a data structure rather than source code or text that a human has written that data structure is then read by the server software to be able to manage itself and that led me on to an idea couldn't I do that more couldn't we keep relational databases in git and so through work we designed a mechanism of doing that sadly we only have about a quarter of an implementation at the moment but now I'm trying to remember exactly the name it is called something to do with music that sounds good begins with a C I've not looked at it in about a year and a half Consonants there you go it's called Consonant and it is a mechanism for putting a schema relational database that can span multiple git repositories into git and if anyone's interested in that kind of thing ideally love someone to come along, have a look at the project read the specification and help us to complete the implementation the partial implementation is currently in Python by the same token if anyone fancies working on a git server I could always do a do with co-maintainers one thing I have used vcsh4 is to just to because for some of you vcsh is basically a way to detach the working tree from the git there which is a fancy way or a complicated way of saying that you are able to use git to maintain files which are not in a git repository which is in the local directory so for example you can have 10 different git working trees in parallel in one directory by keeping all the other things in the background somewhere else without having to care about it we can come back to that later but the thing is what I'm abusing this for is to just save the configuration a local configuration of my git repository so I basically saved the .git config the scripts, the hooks, what have you in a separate repository which is then just an overlay over my main repository and just use this to synchronize the configuration around it so I always have the same configuration in all repositories in all different places where I use those repositories which is quite convenient because all of a sudden you have git for git other people just a question around the workflow does then this git repository actually contain a hidden directory named .git with all the other stuff because git usually refuses to write there unless from the point of view of the of the vcsh repository is stored in your home or xdg config home slash vcsh slash reko.d then you simply have the version tree within the .git of your other repository so it doesn't even realize that this is a git repository because by using this mechanism you avoid this .git detection which makes it not accept anything within it. Anyone else who wants to say anything? I missed the example did anybody talk about annex? no what we are going to I'm just trying to see to feel the room a little bit we'll definitely we turn off the projector maybe I'll have a demo later if people want to but we can hopefully we'll do that quickly enough if we have a demo anyone else wants to sure I'm a student sometimes we have some tasks which we should do in a team and if you're writing documents in a team then it can also help you to keep a bit of record of how much each individual person has contributed so you can also say something like hey you didn't need to write two lines wouldn't you mind sharing something just give us a full request or something so you can keep the team going a bit playing properly that's one other word for it yeah yeah make something you want to stand up and think or you want to say something and everybody is using EDC keeper right? well besides those implementing much easier solutions but if you don't know what a DC keeper is is to keep your slash EDC undergift which is really handy with respect to what was changed yeah but I think it's annoying just the configuration so maybe there are other solutions like Solstice that you can also extend the loan server that you do both the installation and packaging no but this one it's a different use case but that's more like orchestration in this case it's like your personal laptop and you're not usable no but I mean stand alone system so you have your rules and without any server just in your local right but again you need to write them but if you're just a stupid user this way I'm saying that you could use both yeah yeah you can and the thing is it's really very very cheap you just install it, you're literally just installing it has hooks for most package management systems so whenever you install new packages you just save the configuration before and after installation or removal run or whatever you'll have a cron job which saves your conversion every day so if things change you automatically key track for free you don't have to do any work you just have a record of what happened ETC Keeper should have a hook that doesn't allow you to log out if there are unconnected changes so you want talent integration or ETC Keeper you could write what you just commit during shutdown if you wanted to I'm not sure if you wanted to is there a hook to make a push after you know make a commit and it would be nice for me to make also a push you could add whatever hooks you want you mean post push hook to run give push post commit hook after what do you push in the commit change you mean push all commits basically make it work a little bit more yes sure it's quite easy to implement it's trivial no when I migrated away from SVM that was the first thing I did with it to implement exactly this hook and I kept it for I think a week, a week and a half and then the work was just so different if you ever want to change things locally before pushing just clean up your history a little bit if you want to clean up your history or anything if you push up mentally all of a sudden you have the problem that you need to clean up in lots of different places and if someone already pulled from you and then they push again in some situations it might make sense if you for example really have things which are just an ongoing lock for example for ETC keeper it might make sense to just push all your configurations to a different location all the time that would make sense well from the logging perspective it would be better to always pull because then you have one central side which is aware of what machines you could not pull configurations from so I really like pulling over pushing in this context but still in this case it might make sense because you just push out new data all the time but if you actually change things manually I wouldn't recommend pushing out another unless it's a totally private server totally controlled and totally you have access to in which case do whatever you want and fix it when it breaks but else there are some weird people who back up from the data so you could easily include to get pushed for your ETC keeper data into your backup schedule whatever you like for example another use case if there's a command line doing modification to all kinds of configuration files or whatever or there's a web interface and I'm not aware of what it's doing I'm usually just getting it in a directory where it's doing stuff and then just look at the what's actually going on it's quite trivial but it totally useful in such use cases yeah yes I'd just like to push on to the technology stacker we are just a little bit tossing just names around I set a beaker to reserve the last 15 minutes to actually talk about tools which if you just came here to listen and find about a few tools which you may want to use we'll definitely come to that as well so all which have been mentioned yet are on the list to still be talking about so it was first you just for the configuration management of course you need that you are working together that's already told also in front of SoulStack and I find it rather important that you have systems which you can easily track and change because that's one of the reasons I didn't like XML configuration too much because it has a lot of garbage in the diffs also it's completely readable it's definitely better than binary yeah either is good sometimes also in it for example I'm storing a history of PDF documentation for for example because sometimes it's hard to get the documentation from Cisco so it's simply keep a record and you can even later look on what was in the old version also for the documentation you won't get Alex but we'll get to that so as he was first this is more a question and I'll get us one and I won't mention any other version control systems but one of the others that I used previously at the various feature that very repository is a checkout so if I have on my server I have on my repositories in the web space and immediately they are available as websites so it's very easy to publish something just put the repository there you can push there and it'll be there and with Git you have to do some fancy setup you have to post and you have to go there so is there any convenient solution that's not completely a manual about setting up customly written hooks? Yes A, I think the newest version of Git allows you to actually push into non-bare repositories so you can just do this and be done with it What is it called? Push and deploy or something No, push into non-bare There is a name for it I don't know something like before I pushed the default setting is that you are not allowed to push into non-bare repository Hello? The default setting is you are not allowed to push into non-bare repository but you can change the setting But it doesn't checkout It doesn't checkout There is no need for that but even gross effects So in current Git you are actually able to do this but another way which has been used by Git NX in the past is to just have another name space in your branch structure which you push to in non-bare repositories and then just have a hook which simply checks out whatever you have in there to local Or if you want to have two repositories that's the sealed and easiest way just push to a bare repository and have a hook in there which then changes into a non-bare checkout and just pulls the link For everyone when I say bare this basically means it's a server what a server but in simple terms it's what would be on a server non-bare has an actual working directory as in a work tree as in you see the files in the local file system in a bare repository you don't see actual files you only have the objects which can be used to reconstruct the files which you don't want to see I think this was just directly to push to checkout so okay push to checkout the term they're using is push to checkout and they're providing a hook now that's that you can just link in there and which by default refuses to push in their local changes and otherwise it checks them out what is the reason in my opinion is for auto committing changes and maybe auto pushing them is a server which you share among say three administrators and your any type of code configuration management where those administrators make changes they maybe lock them somewhere but you want to keep track of it and just in terms of share backup configuration management in the repository you might just auto commit auto push them so that a person who did a change does not forget it and the next person who will commit it maybe commits the previous changes and yeah well takes the responsibility of this change so well if you auto committing with the current locked in user you won't have this problem as well as specific situation which might not fit for the thing you did and I did too switching from SVM for this yeah but then you really have again the case of one single timeline where you just push stuff away and don't really care about what happens on the other end because you have one single source you have one single timeline and you always push to one single place and you don't care about whatever reason if that's your use case yes that can make sense but I think only then because else if any of those three are not the case I mean I didn't thought about this I documented the plan to do so but this will only work if you don't work in parallel I thought you were first no just I think that's only for if you this was separate or it's not centralized because in Salt Stacker something like so we are using it in that way and we actually have a hook that it's not committed as rules every time you know who committed but I think you are not talking about Salt Stacker function as soon as I did the plan and thought of these problems about people committing changing stuff at the same time to solve some of those problems the answer is also centralized so I would like to speak about MAGIT a little bit which is a NEMAC package for Git and particularly there is a special mode when every time you save a file a file is committed to some special branch named WIP for work in progress and so everything you do is saved on your computer it's not touched anywhere but it's sometimes useful when you do a change on another one and you didn't commit but the last change was mistake, it's there in Git and every time you commit the branch disappeared and you create a new one it's MAGIT it's MAGIT with Minervon sorry I was already talking about what I'm missing is what I would like to know if anyone has a solution for is Git with multiple upstream repositories if you have different branches you can easily vary this branch from there but if you have one branch that has multiple upstream repositories or even multiple branches that come from multiple is there some nice way to keep them in sync or to even see how out of sync they are they are for special cases it's easy to write some shell scripts that does everything for you but is there does anyone know a general solution in this regard I think the most recent release of Git introduced some standardised workflow for triangular development where for example you have your fork of an upstream repository and you're working on your master branch but you want to take changes for upstream's master branch and so they have some workflow for triangular workflows I don't know how extensible that is to sort of octopus workflows but it seems like it would be the obvious place to start if you were looking for something that existed already to work from are you talking about having 10 origins or upstreams which you push to exactly the same thing or which keep different sets of branches it depends sometimes they are the same sometimes for example a private repository is earlier so from my laptop I push to my server and later I want also the private server and the other repository to have all four branches and attacks in sync this starts on my octopus so I'm not shell script sounds good I mean you can create areas so you have for example you can use an alias to overwrite what git push does and then just say in this specific directory if I use git push I'm not even doing the normal push I just run the script instead so you use normal commands and just overwrite them within the context of this specific repository for this kind of problem I have this private git file repository that is on the server computer and I view as git annex sync facility to sync everything so it's the same sync on each on every computer but git annex think will push and pull from the current computer to hold out all those who are back at the time I think both time wise and contextually we are at the point where it makes sense to go into tools which you should not go away from here without having heard of them and written down the name let's start with git annex again I already touched on this earlier basically what git annex does is when you use git annex sync it does also stuff to the objects for a second but what it also does in your master branch is the branch which you have just checked out at the moment and which you are working in it just pushes this to all configured remotes which it can reach and just pushes it into the bare repository into the non-bare repository into special merge branches so the data lives in the other repositories without changing the working directory and as soon as you are there and around again it will just look at all the synchronization branches which whatever other machines push to and just merge it all together as one single large not as one commit but just as one new merge point obviously this tends to break down if you do actual changes to text files or binary or whatever it doesn't matter because as soon as you try to pull in changes from several different sources into one current working directory you've got a problem but if those commits are not conflicting in any way it's a quite brilliant idea to produce good an experience I have to say yeah so tools which you should not leave without writing the name down and maybe having a look later you already said ikimiki those of you who have a website and like to use different markup languages for actually writing it it's kind of admittedly and unfortunately it doesn't really work with the common templates which you find for free on various websites yet it kind of does Joey didn't really want to create a new template which completely works with it so anyway ikimiki has the possibility to have several different backends get be in one of them basically you just edit your local files personally I prefer markdown but you can use what you can write in html and then you just commit you get pushed to your server and there you have a set of hooks which basically compiles all your local files into web pages it takes care of interlinking it takes care of creating footer or navigation on the site or whatever you can have rescaling of images basically whatever you put into your plain text files locally you just push through the server the server compiles it into html once except for for forms and then you have static html on your web server which is very performant for having a random blog or a web page or whatever I just wanted to I mentioned earlier that I think that a really good thing to keep in git is your day log or your journal that kind of thing the way that I do that is I keep it as an ikimiki repository which means that when I'm away from my computers I can still use my phone and the search mechanisms that are built into ikimiki to find stuff that I would otherwise get grep for on my laptop so it really is a very handy mechanism to keep talking about story and documentation what you can also do, what is for example git annex is to just keep all the documentation and the forums and blog posts and everything within one single repository so you have the code, you have all the documentation you have the complete web page, you have all the history of the web page you have all the user questions which were ever asked in one source tree in one large source tree so just by checking out git annex source you have all the information which was ever published within the context of the git annex sites in one single IQ you can just simply generate main pages from this so that's really really useful next thing we've been talking about this quite a lot is git annex git is quite nice but it has one large problem when you check in data this data stays in git if you check it out somewhere else this data also goes to the other checkout for example if you are to use it for your photographs or your videos or it doesn't matter this becomes larger and larger and larger and if you have an SSD in your laptop but you are like me and have two terabytes of photographs which you took over your lifetime this will not fit on your laptop still you would want to have some photos on your laptop and also you probably want to not lose any photos which you took at some point in time so if you put all of this into git annex what git annex does is it creates objects from your files stores them in a separate sub directory and takes care of the management of the information about the files it's basically like storing it's like storing cube cards about files in git keeping git small you basically just save siblings nothingness and then you git annex to actually manage the objects which are standing behind this so for example on my laptop I have a full checkout of all my photographs ever but not one single photograph is on my laptop it's distributed to three external disks and two computers in one server but at the touch of a button I know exactly which photograph is on what machine within seconds simply because I have all the information about the files history in every single repository what I can also do is I can just track changes or track files for example you could just download all your usual podcasts into one directory add them, add them on your server and then just consume whatever you want and then git annex drop so it removes the local copy of the video and then you even have information about it at some point in time I drop this intentionally that we already in the meantime it even allows you to store metadata, arbitrary metadata about files and then create basically like use in a database just changing your whole directory and file structure according to whatever tags you set and select it for example show me all files which were created in 2015 and which have been not deleted yet and which are all files for example so you just drill down within your huge data set and basically create the result of your query within your local file system, very useful you would also have WCSH which you should look at in my opinion basically if you have your contributions in your home directory you spend hours creating your WMARC or whatever and you can also do around what sucks especially at some point you start to do changes and also if you for example use a version you would have one large directory and just some link back into your home which means that you're basically forced to carry all your configuration around everywhere but you may not want to have your M player configuration on the server you may not want to have your SSH and GPG configuration on your work machines so you want to have specific subsets of configuration on this and on that machine so with WCSH what you have is you have one single repository for whatever you choose for example for VI, for ZShell, for M player for VLC, or whatever and are able to contain all the configuration for this one program within one single repository serve this around there's also a built-in mechanism to just pull all the repositories or WCSH repositories or just pull all of those to simplify management of all of a sudden 20 different repositories which live in your home directory without interfering with each other if you want that same mechanism for all your repositories doesn't matter if it's Git, if it's Bazaar if it's Mercurial, if it's Aversion doesn't matter there is MR or in the meantime it has been renamed as MyRepose which basically keeps a list of all your repositories and then you just write MR up once and it updates all your repositories from all sources and then you write MR push and pushes all your repositories to wherever they need to be pushed so for example if you're about to go on holiday and you got half an hour of Wi-Fi at the local airport just MR up MR push once and you're totally synchronized with all your machines yes I'm kind of using this in combination with source code in temp directory so I just have one MR configuration file and when I reboot my machine I can just like create all the source code repositories I'm working on an interest in TMP and you just need to commit and push whatever you do so you can never lose anything yeah that's actually quite a good idea if you want to even go further with that for I have an alternate configuration layout for MyRepose which sadly never made it upstream but it exists where you basically have just like with HTTP I have repositories available which just lists the MR configuration for all my repositories Rito into repositories enabled which are enabled on the local machine which again and this is the real beauty of it allows me to use WeCSH to have one single repository containing all my configuration of all the different repositories which I use and then just choose which to check out by just syn linking from repositories available to repositories enabled that's a really really good workflow it's really really nice and for you case where you basically have TMP temporarily in non-persistent repositories it may even be more useful because then you can just pick and choose which one of them you want to use today and then use MR all the time with that subset of today's packages for repositories I think we are about to be through on it or if you can check out actually there's half an hour of the time we can run over if you want to we don't have to but there's half an hour of downtime one hint on GitK who uses GitK okay who is still scared about let's say we base or reset not hard but reset there are no scared people come on be brave there have been issues in the past replacing stuff specifically doing workflow this was mostly after conversion from SVN so people were not familiar with stuff and we did a lot of I mean let's say the visualized tree looked like a very scary train station and then you have problems with rebasing and stuff if you are using rebasing for example I did some commits to some trunk and I think those commits should not interfere with anything else and if they do I'll get a separate commit tool whatever okay let me just wrap up my question so what I find useful when you start GitK and then you start any rebase or reset and just keep GitK running and then after you are done just hit F5 you get refreshed pointers and refreshed new commits but old tree as well so you could quickly compare the two old state and new state without referring explicitly to reflog so this way you can guarantee that you didn't screw up even better is to use two instances of GitK because then you can compare the old state and the new state so you can just switch between you just have the visual difference between the two GitKs how many monitors do you have? usually two never enough the point is you overlaid the two so you just switch between the two and then you have the visual difference humans are really really good at detecting patterns quickly so this takes a lot of time to just see stuff which you otherwise would have to analyze if anyone of you is working on anything like GitK any visualization tool for Git please please please please please copy what GitHub is doing and use a horizontal timer not a virtual rule that's so much more useful if anyone is working on this please please please please no don't you have a line like this on the top? you also have vertical commit messages yeah but those are only the tags no no you only see the tags and the brush names which are vertical no no no same as in GitK you have the navigation up above and then you just select different points and below you see the actual commit or the diff or whatever so that would be the message Just have two window panes and have horizontal because you have unfortunately these things get wider and wider So you have more horizontal space and still make it option We need more options I don't think it's the case, contrary to two years ago, but just to make sure Anyone wants to talk about this more?