Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "Git Overview - Computerphile" video.

  1. The three basic objects in Git are blobs, trees and commits. A blob represents the contents of a file, and is identified by the SHA-256 hash of its contents. A tree associates names with blobs, and represents a snapshot of source tree contents at a point in time. A commit holds a pointer to a tree, and to zero or more parent commits, as well as information about who did the commit and when, an explanatory comment etc. Trees and commits are also represented by SHA-256 hashes of their contents. This is why a commit holds pointers to its parents, not to its children; because once the commit has been created, it cannot be changed (e.g. to add child pointers) without losing its original SHA-256 ID. Branches and tags are just pointers to particular commits. They have no associated SHA-256 hashes, so they can be added, removed and changed at any time.
    23
  2. If there was any “spite”, it was not on his part, but on that of Larry McVoy in cancelling their BitKeeper licence.
    19
  3. Version control has evolved a lot over the decades. In the beginning, it was thought that it was vital to lock files when somebody checked them out, because if two people made simultaneous changes to the same file, the world would end or something.
    11
  4. Part of it is just text pointers, which are easy enough to examine with regular file tools. E.g. the HEAD file just contains the name of the “current” branch. Unless you have checked out a commit in “headless” mode (what I like to call “Marie Antoinette” mode) ...
    11
  5. That was after the cancellation of the BitKeeper licence.
    8
  6. 9:20 Unlike Subversion, Git does not keep track of what you have checked out at the commit level, only at the branch level. To get around this, it can be helpful to use the “checkout -b” command to create a new, temporary branch pointing to the commit you just checked out. Since this branch is considered “fully merged” (the commit is part of the past history of some branch you really want to keep), you can delete it afterwards with “branch -d” (lowercase d, not uppercase D).
    8
  7. As somebody with a Master of Science degree, you can understand why I might disagree.
    7
  8. Sorry, I kept saying SHA-256. In fact Git still uses SHA-1. Though there is a plan in progress to move to something more future-proof.
    7
  9. pid content tracker”. He deliberately avoided very elaborate conflict-merging schemes, preferring to concentrate on narrowing down the points of conflict so the human user has just the info they need to resolve the issue, without needless distractions. He said he wouldn’t trust his code to more complex automatic mechanisms that many others were proposing. Yes, “clay” is exactly the word that has come to my mind, too. Having all your work safely stored away in the commit history gives you the confidence to take more risks, knowing that, if you screw up, you can always go back. ;)
    7
  10. Rebase is OK for private branches. Once you publish a branch, rebase is going to cause those who pull that branch a lot of grief.
    6
  11.  @BruceHoult  Ho yus! He was the one who violated the terms of the “Don’t Make Larry Unhappy” licence!
    3
  12. and you want to see how much space is being used just by the current source code, not including the version history. If you do du -ks .git . then it shows you the space used by the .git subdirectory, and then it subtracts that from the usage it shows for the “.” directory. Because it knows the earlier directory is contained within the later one!
    3
  13. How would you do it? With text files, you can narrow it down to lines which have changed, and show those lines to a human user. What would the equivalent be for binary files?
    2
  14. If they were using Microsoft Team Foundation Server, you can understand why anything would be seen as an improvement on that ...
    2
  15.  @jursamaj  Now you begin to understand why Git became popular, in spite of the dominance of older, big-name products: it’s because it makes the merge problem actually bearable. With prior VCSes, merging was fraught with difficulties and opportunities to screw things up. With Git, it it actually becomes something you can perform as a routine task.
    2
  16. By the way, fun tip about the “du” command: if you type something like du -ks . that shows you how much disk space is being used by the current directory and its contents. Suppose it contains a .git subdirectory,
    2
  17. I don’t. I still take multiple steps: “git add -u”, check with “git diff --cached”, and then commit. Better to be safe ...
    2
  18. CVS tracked changes on a per-file basis. So if you refactored your code and moved a function from one file to another, that had to be recorded as two separate commits. The problem with this is that, in principle, you have a state of your repo in-between those two commits, where the code is in an inconsistent state. SVN improved on this by allowing the recording of changes to multiple files as a single commit.
    2
  19. If Git is not installed on your production machine, why are you putting Git repos there? You just want the production version of the code, nothing more.
    1
  20. Other VCSes, like SVN, automatically commit all changes you’ve made. Git doesn’t, because you often work on multiple things at once, and might prefer to split them up into separate commits, with handy commands like “git add -p”. If you forget what you’ve changed, “git status” will remind you.
    1
  21. Anyone else notice you can’t mention Git
    1
  22. Hub in the comments?
    1
  23. Remember that Torvalds himself describes Git as the “stu
    1