Recommended: etckeeper to keep all your server’s /etc in git (or. Reading time: 2 – 3 minutes I’m using etckeeper to keep my /etc directory in version control (git). When you make changes to a server, there are always risks. And even if you have a great backup strategy (I recommend backupninja), sometimes you change a config in the wrong way, which can ruin an otherwise great night. Why don’t we have an easy way to version control this very important configuration directory? Here’s what $ sudo gitk will show you after a few changes in your /etc. It’s no surprise that this comes from Joey Hess, who also wrote how to keep your life in svn.
If you’re ready to install, here’s how you do it. That’s it! Whenever you use apt to install a program, it checks in any uncommitted changes, and then checks in the /etc after apt finishes. Here’s another person’s take on etckeeper. 4 Responses to 'Recommended: etckeeper to keep all your server’s /etc in git (or bzr or hg)' Leave a Reply. Git Community Book. Gmane -- philosophy of git. Preface. Git is a version control Swiss army knife. A reliable versatile multipurpose revision control tool whose extraordinary flexibility makes it tricky to learn, let alone master. As Arthur C. Clarke observed, any sufficiently advanced technology is indistinguishable from magic. This is a great way to approach Git: newbies can ignore its inner workings and view Git as a gizmo that can amaze friends and infuriate enemies with its wondrous abilities. Rather than go into details, we provide rough instructions for particular effects. After repeated use, gradually you will understand how each trick works, and how to tailor the recipes for your needs.
I’m humbled that so many people have worked on translations of these pages. Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. François Marier maintains the Debian package originally created by Daniel Baumann. Got Git? HOWTO git and github -- Less Everything Blog. Background: Last week we released the open source social network Lovd By Less. Almost immediately we had requests for people wanting to add code back into Lovd. Lovd had been housed in a private svn repository and distributed via a zip file. This was really good for me, but not so for people that want to take the current version, build on it and later merge whatever newer version of Lovd is available into their app.
Although I hadn't yet tried git I knew that it made this sort of branching a lot easier than subversion, so I decided to try it. Getting started with Github: Github is the new cool git repository website (social network for geeks). Now what? So now I had my git repo setup on github and I started sending out the repo's public address.
Disclaimer: I am still new at git so I may have things wrong, so if you find an error or omission, please say so in the comments. Git explained (I think): Understatement: Git is very different from Subversion. Git clone. OK, so far so good. 1. 2. 3. Git-svn(1) Git svn <command> [options] [arguments] git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository. git svn can track a standard Subversion repository, following the common "trunk/branches/tags" layout, with the --stdlayout option. It can also follow branches and tags in any layout with the -T/-t/-b options (see options to init below, and also the clone command).
Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command. svn.noMetadata svn-remote. This gets rid of the git-svn-id: lines at the end of every commit. This option can only be used for one-shot imports as git svn will not be able to fetch again without metadata.
The git svn log command will not work on repositories using this, either. Svn.useSvmProps svn-remote. svn.useSvnsyncProps svn-remote. An introduction to git-svn for Subversion/SVK users and deserter. This article is aimed at people who want to contribute to projects which are using Subversion as their code-wiki . It is particularly targeted at SVK users, who are already used to a work-flow that involves disconnected operation, though this is a tiny subset of the workflows supported by the git suite.
Subversion users can skip SVK and move straight onto git-svn with this tutorial. People who are responsible for Subversion servers and are converting them to git in order to lay them down to die are advised to consider the one-off git-svnimport , which is useful for bespoke conversions where you don't necessarily want to leave SVN/CVS/etc breadcrumbs behind. I'll mention bespoke conversions at the end of the tutorial, and the sort of thing that you end up doing with them. This is quite different from the Git - SVN Crash Course on the Git home page, which is intended for people who are familiar with Subversion who want to work with Git mastered projects using Git.
Sam Vilain Contents: What!? Git User's Manual (for version 1.5.3 or newer) This chapter covers internal details of the Git implementation which probably only Git developers need to understand. A birds-eye view of Git’s source code It is not always easy for new developers to find their way through Git’s source code. This section gives you a little guidance to show where to start. A good place to start is with the contents of the initial commit, with: $ git checkout e83c5163 The initial revision lays the foundation for almost everything Git has today, but is small enough to read in one sitting.
Note that terminology has changed since that revision. Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.h. If you grasp the ideas in that initial commit, you should check out a more recent version and skim cache.h, object.h and commit.h. In the early days, Git (in the tradition of UNIX) was a bunch of programs which were extremely simple, and which you used in scripts, piping the output of one into another. Now, for the meat: Git magic. Git User's Manual (for version 1.5.3 or newer) This chapter covers internal details of the git implementation which probably only git developers need to understand. It is not always easy for new developers to find their way through Git’s source code. This section gives you a little guidance to show where to start. A good place to start is with the contents of the initial commit, with: $ git checkout e83c5163 The initial revision lays the foundation for almost everything git has today, but is small enough to read in one sitting.
Note that terminology has changed since that revision. Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.h. If you grasp the ideas in that initial commit, you should check out a more recent version and skim cache.h, object.h and commit.h. In the early days, Git (in the tradition of UNIX) was a bunch of programs which were extremely simple, and which you used in scripts, piping the output of one into another. Next step: get familiar with the object naming. Voila.