background preloader

Git for Computer Scientists

Git for Computer Scientists
Abstract Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph. Storage In simplified form, git object storage is "just" a DAG of objects, with a handful of different types of objects. They are all stored compressed and identified by an SHA-1 hash (that, incidentally, isn't the SHA-1 of the contents of the file they represent, but of their representation in git). blob: The simplest object, just a bunch of bytes. tree: Directories are represented by tree object. When a node points to another node in the DAG, it depends on the other node: it cannot exist without it. commit: A commit refers to a tree that represents the state of the files at the time of the commit. refs: References, or heads or branches, are like post-it notes slapped on a node in the DAG. git commit adds a node to the DAG and moves the post-it note for current branch to this new node. The HEAD ref is special in that it actually points to another ref. History

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. Rather than go into details, we provide rough instructions for particular effects. 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. My gratitude goes to many others for your support and praise. If I’ve left you out by mistake, please tell me or just send me a patch! This guide is released under the GNU General Public License version 3. $ git clone # Creates "gitmagic" directory. or from one of the mirrors:

Abstractivate: Why Functional Matters: Your white board will never be the same Why learn functional programming? For better design skills! The other day we designed a process to match cleared deposits with dispensations. This is how I would have white-boarded it a few years ago: Since then I've played around with functional programming. Thinking about the problem in this way leads to this kind of diagram: Thinking about the program as a data pipeline keeps me thinking about what needs to happen, instead of how each step should be done. Whatever language we use to write the solution, thinking about it this way has the following advantages: * It breaks down into pieces. In this way, thinking functionally helps with agile (task breakdown), TDD, and maintainability. For how functional thinking helps at a lower level too, check this post. New coding tricks are fun, but new white board techniques are serious business.

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:

How to create patch file using patch and diff November 23rd, 2006 mysurface Posted in Developer, diff, Misc, patch | Hits: 323569 | 14 Comments » Okay, this is what I do. I only know the basic. But before doing this, please backup your source code, patch wrongly will screwup your source code. First, how to create patch file? Assume Original source code at folder Tb01, and latest source code at folder Tb02. diff -crB Tb01 Tb02 > Tb02.patch -c context, -r recursive (multiple levels dir), -B is to ignore Blank Lines. How to patch? Doing dry-run like this: patch --dry-run -p1 -i Tb02.patch The success output looks like this: patching file TbApi.cpp patching file TbApi.h patching file TbCard.cpp ... The failure ouptut looks like this: patching file TbCard.cpp Hunk #2 FAILED at 585. 1 out of 2 hunks FAILED -- saving rejects to file TbCard.cpp.rej patching file TbCard.h Hunk #1 FAILED at 57. At last, if the dry-run is giving good result, do this and enjoy the compilation. patch -p1 -i Tb02.patch References: 1.

Understanding Git Conceptually Introduction This is a tutorial on the Git version control system. Git is quickly becoming one of the most popular version control systems in use. A Story When I first started using Git, I read plenty of tutorials, as well as the user manual. After a few months, I started to understand those under-the-hood concepts. Understanding Git The conclusion I draw from this is that you can only really use Git if you understand how Git works. Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. This tutorial, then, will take a conceptual approach to Git. Go on to the next page: Repositories

SixthSense - a wearable gestural interface (MIT Media Lab) 'SixthSense' is a wearable gestural interface that augments the physical world around us with digital information and lets us use natural hand gestures to interact with that information. We've evolved over millions of years to sense the world around us. When we encounter something, someone or some place, we use our five natural senses to perceive information about it; that information helps us make decisions and chose the right actions to take. The SixthSense prototype is comprised of a pocket projector, a mirror and a camera. The SixthSense prototype implements several applications that demonstrate the usefulness, viability and flexibility of the system. The current prototype system costs approximate $350 to build. . . . some more pictures are coming soon. . . . more videos are coming soon, too. P.

Git - SVN Crash Course Welcome to the Git version control system! Here we will briefly introduce you to Git usage based on your current Subversion knowledge. You will need the latest Git installed; There is also a potentially useful tutorial in the Git documentation. This page is not maintained anymore! How to Read Me In those small tables, at the left we always list the Git commands for the task, while at the right the corresponding Subversion commands you would use for the job are listed. Before running any command the first time, it's recommended that you at least quickly skim through its manual page. Things You Should Know There are couple important concepts it is good to know when starting with Git. Repositories. Commiting For the first introduction, let's make your project tracked by Git and see how we get around to do daily development in it. Now your tree is officially tracked by Git. That's it. Git embeds special information in the diffs about adds, removals and mode changes: Browsing Merging Going Remote

Git from the bottom up In my pursuit to understand Git, it’s been helpful for me to understand it from the bottom up — rather than look at it only in terms of its high-level commands. And since Git is so beautifully simple when viewed this way, I thought others might be interested to read what I’ve found, and perhaps avoid the pain I went through finding it. The following article offers what I’ve learned on this journey so far. I hope it can help others to comprehend this wonderful system, and discover some of the joy I’ve experienced in the past few weeks. NOTE: After receiving more than fifty corrections by e-mail from very helpful readers, I’ve updated the PDF to reflect their input. The date at the front should read “December 2009″ if you have the latest version. Here is a summary from the table of contents:

training (The GitHub Training Team)