24 ms·

Git from the inside out

284 points by luu 12y ago

AceJohnny2 12y ago
See also "Git from the Bottom Up": https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/ (originally a PDF in 2008)
- dwyer 12y ago
  Much better article IMO. Introducing the low level commands that the higher level ones wrap around is a much more fun and interactive way to understand the .git schema to me.
ams6110 12y ago
Yet another attempt to explain the incomprehensible. Why does such a popular version control systems find itself in need of so many explanatations. Any startup attempting to market something that required a user to understand concepts such as this... https://codewords.recurse.com/images/two/git-from-the-inside-out/24-13.png https://codewords.recurse.com/images/two/git-from-the-inside... ...would be laughed out of the room in any other context.
- rudolf0 12y ago
  Git isn't exactly a startup (or a company, or even a product), nor did it ever intend to be. Lots of great software happens to be difficult for a lot of people to intuitively understand.
  - Crito 12y ago
    > "Lots of great software happens to be difficult for a lot of people to intuitively understand." For real. Maybe it is just me, but I find programs like Photoshop and nearly every CAD program I've ever encountered to be bewilderingly complicated. I don't use any of those sorts of software professionally, but have found myself needing them numerous times for hobby reasons. Every time I try to learn them I become frustrated with just how steep and tall the learning curves are. Git though? I felt pretty confident with how it worked and basic command line operation after just a weekend. Maybe git's command line is more inconsistent than hg's or subversions', but in the grand scheme of software difficulty? I just don't get the complaints. "Incomprehensible"? Give me a break. It does not hold a candle to most commercial professional software.
- sp332 12y ago
  You are not required to understand this concept. But if you're working on a large team and your branch history gets this complicated, you can still effectively use git to manage it. Try that with less-popular version control systems. (Mercurial comes to mind, actually.)
  - imakesnowflakes 12y ago
    What is it that you can do in git, that you can't do in Mercurial?
    - bsder 12y ago
      Stop. You can't argue with git fanboys. git is the One True Way(tm). Windows doesn't exist. Linus (praised be his name) says so.
    - kinghajj 12y ago
      I believe one piece still missing is the full functionality provided by the index in Git. There is the record extension, but IIRC that doesn't emulate one of the index's greatest features: during a merge/rebase, non-conflicting changes are already staged, so "git diff" shows only conflicts (and "git diff --cached" shows those changes that merged successfully).
      - imakesnowflakes 12y ago
        Mercurial does this, and you only have to manually resolve conflicting changes during a merge/rebase. See here http://mercurial.selenic.com/wiki/MergeToolConfiguration http://mercurial.selenic.com/wiki/MergeToolConfiguration I think you might have tried this on a instance of Mercurial where the "premerge" option of the merge tool has been turned off for some reason..
- dr4g0n 12y ago
  A version control system with the feature set git has is necessarily complicated, this is not a bad thing. Forcing the complexity on the user is a bad thing, but git does not do this except when it is necessary to. Using git at a basic level is not hard. This essay is not attempting to explain how to use git, it is explaining how git itself works and how changes are physically tracked. There's no need for a basic user to know this information, but if someone wants to dig into git and understand how it works, this essay is a nice guide. Explaining how SVN or any other version control system works at this level of detail would also be complicated.
- semi-extrinsic 12y ago
  So by your logic, we shouldn't have helicopters? Using them arguably requires a lot more understanding of complicated things than git does.
- sergiotapia 12y ago
  Git won because of Github, it's an unpopular opinion but I stand by it. If Github did not exist, Git wouldn't have been adopted by so many projects.
  - josteink 12y ago
    > Git won because of Github, it's an unpopular opinion but I stand by it. Quite often you will find the exact opposite statement: Github succeeded because it rode on the success of Git. I'm not saying your position is wrong, but they cannot both be right.
- brown9-2 12y ago
  Sometimes technical things are complicated, because people don't work or communicate in tidy ways. You could make similar complaints about many of the foundations that make technology possible. Take for example a protocol that enabled you to read this message: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#/media/File:Tcp_state_diagram_fixed_new.svg http://en.wikipedia.org/wiki/Transmission_Control_Protocol#/...
leni536 12y ago
> from inside out As a physicist it always surprises me how thinking between physicist and programmers most of the time is kind of reversed. Most git tutorials seem like this to me (Mechanics analogy): 1. Slopes 2. Springs and gears 3. Horrendous contraptions 4. Ropes and pulleys ... 9. Newton I., II. and III. These kind of "inside out" tutorials are natural for me and recently I taught git basics to my SO in a similar way. It worked out well (she is a physicist too). I don't want to generalize though, it's maybe rooted in the common ways of teaching programming and physics.
- RickHull 12y ago
  It has to do whether the audience already has a solid theoretic / symbolic / formal background. Do they already think in terms of models? For graduate level physicists, this is almost surely the case. Most git tutorials are for people who need to get up to speed quickly, having had git imposed on them from above, mapping surface area concepts from the prior version control system. Hard core engineers with an interest find their way to the theoretic center.
- joshuapants 12y ago
  I think this is generally because people want to start Doing Things right away with what they're learning, so most teaching attempts revolve around giving the student something they can Do and then explaining it afterward.
- JoshTriplett 12y ago
  Imagine if everyone learning physics came in with an attitude of "I need to learn and use the rocket equation as quickly as possible" (or substitute some other high-level problem for "the rocket equation"). You'd end up with strange backwards tutorials for physics that start out with that specific model, then a handful of related models, then how to abuse that model to handle things it doesn't really apply to, and much later the underlying physics and mathematics to solve arbitrary generalized problems. Many people start out trying to figure out either "how do I use git exactly like (svn, cvs, vss, ...)" or "how do I commit and push my changes", so tutorials start there. Most people don't approach git by learning its underlying data model. Arguably people should, because it's a rather simple data model, and then all the commands become simple applications of that model.
dnc 12y ago
For grokking git, indispensable resource is git early dev mailing list and corresponding code base (first couple of months after project started). Linus explained it in very clear and precise way in the mailing list and related code. The initial code base is surprisingly small (around 1200 LOC of clear and precise C code). Used data structures are simple and self-explanatory. Although most of the original code is not in the git code base anymore, the data structures and main design ideas have stayed there intact so far.
- voltagex_ 12y ago
  I'm going to have to go through the archives later (anyone got an mbox?) but it's tricky to follow the early development. The archives seem to start at http://marc.info/?l=git&r=20&b=200504&w=2 http://marc.info/?l=git&r=20&b=200504&w=2 and I don't see many design messages from Linus.
- coldpie 12y ago
  I actually found gitcore-tutorial(7) to be a really great resource when I was learning git.
jordigh 12y ago
Huh, another git explanation. Either the thing is so easy to understand that everyone can do it and is then compelled to write about it, or it's so difficult to understand that everyone feels the compulsion to explain it to everyone else.
- RickHull 12y ago
  Maybe a quip, but that dichotomy is so false it's not even funny. Git is tough to wrap one's head around at first. It's not intuitive unless one already has a deep background in this space. Hence, there are lots of attempts to explain it in order to bring more into the fold of intuition. It seems perfectly natural and good, and your contemptuous tone puzzles me.
  - Dylan16807 12y ago
    Right. It's simple but it's unfamiliar. Confusing command parameters aside.
- ta0967 12y ago
  Its concepts easy to understand and git is very powerful, but the interface is horrible and a bitch to learn. Git does not need another tutorial, it needs an alternative porcelain.
  - bsder 12y ago
    git has been out how long now? How many people bitch about its bad user interface? And yet nobody as stepped up to write something better? Perhaps this is pointing to the fact that there is something fundamental about git that prevents such a thing from happening?
    - ta0967 12y ago
      Prevents? There's nothing like that. The only something about git that hampers comprehensive porcelain alternatives is the lack of orthogonality in git's plumbing. People spent years bitching about CVS before a few Apache-related people got together and wrote Subversion. The long time it took didn't point to anything fundamental about CVS preventing anything.
chx 12y ago
Regular pitch for http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something. It's concise (the linked article is gigantic) and allows for an understanding of this overhyped user hostile DVCS. I know that git won but don't expect me to be happy about it.
- fit2rule 12y ago
  I found this tutorial (the one you recommend) to be, generally, terrible. It doesn't define terms, but rather just jumps into the git terminology without explaining things. For example the section on "Commit Objects" - what actually is a commit object? Is it a directory, is it a special file, is it .. something else? The term is used in an abstract manner without actually explaining what the term means - sure, it explains what is associated with the term, but why is it an object? The same goes for the "Heads" explanation - its a reference to a commit object. Is this a softlink, is it a field in a special file that contains a reference .. what "is it?", and why is the word "head" used? Whereas in the tutorial referred to in this article, "Git From the Inside Out", the terms are actually defined before they're used in any significant fashion. "Commit Objects = After creating the tree graph, git commit creates a commit object. This is just another text file in .git/objects/:" (with example), and .. "Heads = Which is the current branch? To find out, Git goes to the HEAD file at .git/HEAD and finds: ref: refs/heads/master This says that HEAD is pointing at master. master is the current branch." I just want to point this difference out, because it actually is endemic in all Git tutorials I've found - either you define the basic terms, such that an association can be made in the mind of the reader, allowing them to grasp the abstractions .. or you don't. This appears to be a common problem with Git tutorials, in my opinion - the terms, or rather the taxology of the Git abstractions - are quite unclear. Why on earth the term "Head" is used to refer to a commit object is quite un-intuitive .. at first. Git really requires a deeper dive into the abstractions before surfacing for true understanding.
- barbs 12y ago
  What alternative do you prefer?
kazinator 12y ago
Wish `git` didn't have annoying special cases in it. For instance git rebase -i HEAD~2 won't work if there are only two commits, because HEAD~2 refers to a nonexistent commit after the first two. There should be some friggin' NIL terminator there which takes the HEAD~2 reference. Imagine having a function to, say, delete characters from a string which takes an open-ended range [from, to). Then imagine that the index to has to exist in the string; it must not point one element past the end! Oops, you cannot delete from a position to the end of the string. The garbage-collected object graph is nice and "Lisp-like" in some ways, but silly in others. Oh, and in case you're thinking "just make an empty initial commit, and it will effectively be your NIL terminator". No can do; git doesn't allow empty commits. Of course, you can make a file called ".nil" and add it and commit. Use "()" as the commit comment. :)
- chx 12y ago
  git commit --allow-empty
  - kazinator 12y ago
    Thanks; that is perfect. I just tried that it works on the root commit in a newly initialized repo. I will always do this from now on: $ git init $ git commit --allow-empty -m NIL Maybe the git maintainers can be persuaded to make a "git init --nil" which does this in one step.
    - mitchty 12y ago
      Eh, just make an alias in ~/.gitconfig no need to add more options to git. That is: [alias] nilinit = !sh -c 'git init && git commit --allow-empty -m NIL' And now git nilinit does what you want.
      - kazinator 12y ago
        The problem is that what I want is for "git init --nil" to do that, not for some "git nilinit". Actually, I want "git init" to do that by default! Every git repo should begin with an empty commit. In fact, there should be a special SHA built in representing the empty commit; perhaps an all-zero SHA. This object is understood not to occupy any space in the object store beyond its own SHA: you don't look for an all zero SHA in the object space; it just stands for itself. Then this same can be used as a parent in any orphan branch. One of the benefits is that this zero SHA is global. And so all git repos have a common ancestor automatically. If you and I take some code tarball (the same one) and start git repos individually, then we implicitly have a common merge-base: the NIL commit. If I pull from your repo, then we have this: your-import <--- your-hacks / NIL \ my-import <--- my-hacks your-import and my-import are the same since we imported the same thing. I can just do a "git rebase your-hacks-branch" to transplant my-hacks over your-hacks, implicitly using NIL as the merge-base.
ThinkBeat 12y ago
What tool did the poster use to create the diagrams?
- maryrosecook 12y ago
  OmniGraffle. I really enjoy using it.
mendelk 12y ago
Interesting article. Also wasn't aware that Hacker School changed their name. https://www.recurse.com/blog/77-hacker-school-is-now-the-recurse-center https://www.recurse.com/blog/77-hacker-school-is-now-the-rec...
- chromedude 12y ago
  Don't worry you aren't very far behind the times. It was announced yesterday.
Fannon 12y ago
A great title would have been: The Guts of Git.
- a3_nm 12y ago
  Already taken: https://lwn.net/Articles/131657/ https://lwn.net/Articles/131657/
logicallee 12y ago
>"This essay explains how Git works. It assumes you understand Git well enough to use it to version control your projects." so...the opposite of Bjarne Stroustrup's maligned "The C++ Programming Language", which fails to explain how C++ works, after assuming you don't know it. :) seriously though no need for the second sentence. this article is a great intro!
msie 12y ago
I regular read articles about Git's inner workings and I always seem to forget it. :-(
RansomTime 12y ago
Footnote 3: git prune deletes all objects that cannot be reached from a ref. If the user runs this command, they may lose content. In what cases would a user lose content? When something is added but not committed only?
- m0tive 12y ago
  When you've committed something, but then rebased or reset the branch position so the commit is not longer in the history of any branch or tag. This usually isn't a problem, because when you rebase work you are making a copy of the commit so references to the data should be the same. I also think it's worth noting, `git gc`, which is triggered automatically occasionally, actually runs `git prune`.
RansomTime 12y ago
Footnote 3: git prune deletes all objects that cannot be reached from a ref. If the user runs this command, they may lose content. In what cases would a user lose content? When something is added but not committed only?

284 points by luu 12y ago

See also "Git from the Bottom Up": https://jwiegley.github.io/git-from-the-bottom-up/ https://jwiegley.github.io/git-from-the-bottom-up/ (originally a PDF in 2008)

dwyer 12y ago
Much better article IMO. Introducing the low level commands that the higher level ones wrap around is a much more fun and interactive way to understand the .git schema to me.

ams6110 12y ago

Yet another attempt to explain the incomprehensible. Why does such a popular version control systems find itself in need of so many explanatations. Any startup attempting to market something that required a user to understand concepts such as this... https://codewords.recurse.com/images/two/git-from-the-inside-out/24-13.png https://codewords.recurse.com/images/two/git-from-the-inside... ...would be laughed out of the room in any other context.

rudolf0 12y ago
Git isn't exactly a startup (or a company, or even a product), nor did it ever intend to be. Lots of great software happens to be difficult for a lot of people to intuitively understand.
- Crito 12y ago
  > "Lots of great software happens to be difficult for a lot of people to intuitively understand." For real. Maybe it is just me, but I find programs like Photoshop and nearly every CAD program I've ever encountered to be bewilderingly complicated. I don't use any of those sorts of software professionally, but have found myself needing them numerous times for hobby reasons. Every time I try to learn them I become frustrated with just how steep and tall the learning curves are. Git though? I felt pretty confident with how it worked and basic command line operation after just a weekend. Maybe git's command line is more inconsistent than hg's or subversions', but in the grand scheme of software difficulty? I just don't get the complaints. "Incomprehensible"? Give me a break. It does not hold a candle to most commercial professional software.
sp332 12y ago
You are not required to understand this concept. But if you're working on a large team and your branch history gets this complicated, you can still effectively use git to manage it. Try that with less-popular version control systems. (Mercurial comes to mind, actually.)
- imakesnowflakes 12y ago
  What is it that you can do in git, that you can't do in Mercurial?
  - bsder 12y ago
    Stop. You can't argue with git fanboys. git is the One True Way(tm). Windows doesn't exist. Linus (praised be his name) says so.
  - kinghajj 12y ago
    I believe one piece still missing is the full functionality provided by the index in Git. There is the record extension, but IIRC that doesn't emulate one of the index's greatest features: during a merge/rebase, non-conflicting changes are already staged, so "git diff" shows only conflicts (and "git diff --cached" shows those changes that merged successfully).
    - imakesnowflakes 12y ago
      Mercurial does this, and you only have to manually resolve conflicting changes during a merge/rebase. See here http://mercurial.selenic.com/wiki/MergeToolConfiguration http://mercurial.selenic.com/wiki/MergeToolConfiguration I think you might have tried this on a instance of Mercurial where the "premerge" option of the merge tool has been turned off for some reason..
dr4g0n 12y ago
A version control system with the feature set git has is necessarily complicated, this is not a bad thing. Forcing the complexity on the user is a bad thing, but git does not do this except when it is necessary to. Using git at a basic level is not hard. This essay is not attempting to explain how to use git, it is explaining how git itself works and how changes are physically tracked. There's no need for a basic user to know this information, but if someone wants to dig into git and understand how it works, this essay is a nice guide. Explaining how SVN or any other version control system works at this level of detail would also be complicated.
semi-extrinsic 12y ago
So by your logic, we shouldn't have helicopters? Using them arguably requires a lot more understanding of complicated things than git does.
sergiotapia 12y ago
Git won because of Github, it's an unpopular opinion but I stand by it. If Github did not exist, Git wouldn't have been adopted by so many projects.
- josteink 12y ago
  > Git won because of Github, it's an unpopular opinion but I stand by it. Quite often you will find the exact opposite statement: Github succeeded because it rode on the success of Git. I'm not saying your position is wrong, but they cannot both be right.
brown9-2 12y ago
Sometimes technical things are complicated, because people don't work or communicate in tidy ways. You could make similar complaints about many of the foundations that make technology possible. Take for example a protocol that enabled you to read this message: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#/media/File:Tcp_state_diagram_fixed_new.svg http://en.wikipedia.org/wiki/Transmission_Control_Protocol#/...

leni536 12y ago

> from inside out As a physicist it always surprises me how thinking between physicist and programmers most of the time is kind of reversed. Most git tutorials seem like this to me (Mechanics analogy): 1. Slopes 2. Springs and gears 3. Horrendous contraptions 4. Ropes and pulleys ... 9. Newton I., II. and III. These kind of "inside out" tutorials are natural for me and recently I taught git basics to my SO in a similar way. It worked out well (she is a physicist too). I don't want to generalize though, it's maybe rooted in the common ways of teaching programming and physics.

RickHull 12y ago
It has to do whether the audience already has a solid theoretic / symbolic / formal background. Do they already think in terms of models? For graduate level physicists, this is almost surely the case. Most git tutorials are for people who need to get up to speed quickly, having had git imposed on them from above, mapping surface area concepts from the prior version control system. Hard core engineers with an interest find their way to the theoretic center.
joshuapants 12y ago
I think this is generally because people want to start Doing Things right away with what they're learning, so most teaching attempts revolve around giving the student something they can Do and then explaining it afterward.
JoshTriplett 12y ago
Imagine if everyone learning physics came in with an attitude of "I need to learn and use the rocket equation as quickly as possible" (or substitute some other high-level problem for "the rocket equation"). You'd end up with strange backwards tutorials for physics that start out with that specific model, then a handful of related models, then how to abuse that model to handle things it doesn't really apply to, and much later the underlying physics and mathematics to solve arbitrary generalized problems. Many people start out trying to figure out either "how do I use git exactly like (svn, cvs, vss, ...)" or "how do I commit and push my changes", so tutorials start there. Most people don't approach git by learning its underlying data model. Arguably people should, because it's a rather simple data model, and then all the commands become simple applications of that model.

dnc 12y ago

For grokking git, indispensable resource is git early dev mailing list and corresponding code base (first couple of months after project started). Linus explained it in very clear and precise way in the mailing list and related code. The initial code base is surprisingly small (around 1200 LOC of clear and precise C code). Used data structures are simple and self-explanatory. Although most of the original code is not in the git code base anymore, the data structures and main design ideas have stayed there intact so far.

voltagex_ 12y ago
I'm going to have to go through the archives later (anyone got an mbox?) but it's tricky to follow the early development. The archives seem to start at http://marc.info/?l=git&r=20&b=200504&w=2 http://marc.info/?l=git&r=20&b=200504&w=2 and I don't see many design messages from Linus.
coldpie 12y ago
I actually found gitcore-tutorial(7) to be a really great resource when I was learning git.

jordigh 12y ago

Huh, another git explanation. Either the thing is so easy to understand that everyone can do it and is then compelled to write about it, or it's so difficult to understand that everyone feels the compulsion to explain it to everyone else.

RickHull 12y ago
Maybe a quip, but that dichotomy is so false it's not even funny. Git is tough to wrap one's head around at first. It's not intuitive unless one already has a deep background in this space. Hence, there are lots of attempts to explain it in order to bring more into the fold of intuition. It seems perfectly natural and good, and your contemptuous tone puzzles me.
- Dylan16807 12y ago
  Right. It's simple but it's unfamiliar. Confusing command parameters aside.
ta0967 12y ago
Its concepts easy to understand and git is very powerful, but the interface is horrible and a bitch to learn. Git does not need another tutorial, it needs an alternative porcelain.
- bsder 12y ago
  git has been out how long now? How many people bitch about its bad user interface? And yet nobody as stepped up to write something better? Perhaps this is pointing to the fact that there is something fundamental about git that prevents such a thing from happening?
  - ta0967 12y ago
    Prevents? There's nothing like that. The only something about git that hampers comprehensive porcelain alternatives is the lack of orthogonality in git's plumbing. People spent years bitching about CVS before a few Apache-related people got together and wrote Subversion. The long time it took didn't point to anything fundamental about CVS preventing anything.

chx 12y ago

Regular pitch for http://www.sbf5.com/~cduan/technical/git/ http://www.sbf5.com/~cduan/technical/git/ > you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something. It's concise (the linked article is gigantic) and allows for an understanding of this overhyped user hostile DVCS. I know that git won but don't expect me to be happy about it.

fit2rule 12y ago
I found this tutorial (the one you recommend) to be, generally, terrible. It doesn't define terms, but rather just jumps into the git terminology without explaining things. For example the section on "Commit Objects" - what actually is a commit object? Is it a directory, is it a special file, is it .. something else? The term is used in an abstract manner without actually explaining what the term means - sure, it explains what is associated with the term, but why is it an object? The same goes for the "Heads" explanation - its a reference to a commit object. Is this a softlink, is it a field in a special file that contains a reference .. what "is it?", and why is the word "head" used? Whereas in the tutorial referred to in this article, "Git From the Inside Out", the terms are actually defined before they're used in any significant fashion. "Commit Objects = After creating the tree graph, git commit creates a commit object. This is just another text file in .git/objects/:" (with example), and .. "Heads = Which is the current branch? To find out, Git goes to the HEAD file at .git/HEAD and finds: ref: refs/heads/master This says that HEAD is pointing at master. master is the current branch." I just want to point this difference out, because it actually is endemic in all Git tutorials I've found - either you define the basic terms, such that an association can be made in the mind of the reader, allowing them to grasp the abstractions .. or you don't. This appears to be a common problem with Git tutorials, in my opinion - the terms, or rather the taxology of the Git abstractions - are quite unclear. Why on earth the term "Head" is used to refer to a commit object is quite un-intuitive .. at first. Git really requires a deeper dive into the abstractions before surfacing for true understanding.
barbs 12y ago
What alternative do you prefer?

kazinator 12y ago

Wish `git` didn't have annoying special cases in it. For instance git rebase -i HEAD~2 won't work if there are only two commits, because HEAD~2 refers to a nonexistent commit after the first two. There should be some friggin' NIL terminator there which takes the HEAD~2 reference. Imagine having a function to, say, delete characters from a string which takes an open-ended range [from, to). Then imagine that the index to has to exist in the string; it must not point one element past the end! Oops, you cannot delete from a position to the end of the string. The garbage-collected object graph is nice and "Lisp-like" in some ways, but silly in others. Oh, and in case you're thinking "just make an empty initial commit, and it will effectively be your NIL terminator". No can do; git doesn't allow empty commits. Of course, you can make a file called ".nil" and add it and commit. Use "()" as the commit comment. :)

chx 12y ago
git commit --allow-empty
- kazinator 12y ago
  Thanks; that is perfect. I just tried that it works on the root commit in a newly initialized repo. I will always do this from now on: $ git init $ git commit --allow-empty -m NIL Maybe the git maintainers can be persuaded to make a "git init --nil" which does this in one step.
  - mitchty 12y ago
    Eh, just make an alias in ~/.gitconfig no need to add more options to git. That is: [alias] nilinit = !sh -c 'git init && git commit --allow-empty -m NIL' And now git nilinit does what you want.
    - kazinator 12y ago
      The problem is that what I want is for "git init --nil" to do that, not for some "git nilinit". Actually, I want "git init" to do that by default! Every git repo should begin with an empty commit. In fact, there should be a special SHA built in representing the empty commit; perhaps an all-zero SHA. This object is understood not to occupy any space in the object store beyond its own SHA: you don't look for an all zero SHA in the object space; it just stands for itself. Then this same can be used as a parent in any orphan branch. One of the benefits is that this zero SHA is global. And so all git repos have a common ancestor automatically. If you and I take some code tarball (the same one) and start git repos individually, then we implicitly have a common merge-base: the NIL commit. If I pull from your repo, then we have this: your-import <--- your-hacks / NIL \ my-import <--- my-hacks your-import and my-import are the same since we imported the same thing. I can just do a "git rebase your-hacks-branch" to transplant my-hacks over your-hacks, implicitly using NIL as the merge-base.

ThinkBeat 12y ago

What tool did the poster use to create the diagrams?

maryrosecook 12y ago
OmniGraffle. I really enjoy using it.

mendelk 12y ago

Interesting article. Also wasn't aware that Hacker School changed their name. https://www.recurse.com/blog/77-hacker-school-is-now-the-recurse-center https://www.recurse.com/blog/77-hacker-school-is-now-the-rec...

chromedude 12y ago
Don't worry you aren't very far behind the times. It was announced yesterday.

Fannon 12y ago

A great title would have been: The Guts of Git.

a3_nm 12y ago
Already taken: https://lwn.net/Articles/131657/ https://lwn.net/Articles/131657/

logicallee 12y ago

>"This essay explains how Git works. It assumes you understand Git well enough to use it to version control your projects." so...the opposite of Bjarne Stroustrup's maligned "The C++ Programming Language", which fails to explain how C++ works, after assuming you don't know it. :) seriously though no need for the second sentence. this article is a great intro!

msie 12y ago

I regular read articles about Git's inner workings and I always seem to forget it. :-(

RansomTime 12y ago

Footnote 3: git prune deletes all objects that cannot be reached from a ref. If the user runs this command, they may lose content. In what cases would a user lose content? When something is added but not committed only?

m0tive 12y ago
When you've committed something, but then rebased or reset the branch position so the commit is not longer in the history of any branch or tag. This usually isn't a problem, because when you rebase work you are making a copy of the commit so references to the data should be the same. I also think it's worth noting, `git gc`, which is triggered automatically occasionally, actually runs `git prune`.

RansomTime 12y ago