Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "Inside the Hidden Git Folder - Computerphile" video.

  1. 7:50 Some people might be accustomed to other VCSes which automatically assume that every change you have made to your working copy is to be included in the next commit (e.g. Subversion works this way). Git doesn’t do this -- it requires you to explicitly add changes to the “index” to be included in the commit. This is because Git recognizes that you often make multiple sets of changes -- for example, while fixing one thing, you notice something else that needs fixing, that is quite unrelated. So when you actually get round to committing your changes, you can pick and choose which ones go into the same commit, and which ones to leave for another separate commit. And some things, like debug message lines, can be left out altogether.
    62
  2. 3:41 Tip: You can do “git show --raw «commit»” to get a list of the files affected by that commit. You can similarly list the files affected by each entry in the log with “git log --raw”.
    21
  3. 5:22 You can set your working directory to any subdirectory of a project directory. Git will automatically go up into parent directories until it finds one containing a .git subdirectory, or until it hits a filesystem boundary, at which point it gives up.
    12
  4. I think it is quite common to clean up and simplify your private commit history before sending a bunch of patches to the central authorities for a project. For example, you probably don’t want them seeing every little typo correction or whitespace fixup as a separate commit.
    9
  5. In Windows, the usual answer if some procedure gives you trouble is: “have you tried running it as Administrator?”
    7
  6. It’s actually a “directed acyclic graph”. A commit can have a single parent, multiple parents (merge commit) or even no parents at all (like the first commit in a repo). Trivia question: can there be more than one commit in a repo with no parents?
    5
  7. I would have to say, [citation needed].
    3
  8. As I recall, one reason why a lot of that simplicity had to go away was because shell scripts and subprocesses do not work well under Microsoft Windows. I think this was about the time Mozilla were looking to move to one of these newfangled distributed VCS things (likely they were using Subversion before). But one important criterion was that it had to work well under Windows. Sadly, that ruled out Git (at the time). So they went with Mercurial instead.
    3
  9.  @Richardincancale  I’m sure there were smart researchers at IBM, but somehow their shipping products rarely reflected that -- they were clunky, resource-hungry and overcomplicated compared to, say, DEC and Unix systems.
    2
  10. Macs are the ultimate example of how something can officially license the “Unix” name, yet work nothing like people expect a traditional “Unix” system to work.
    2
  11. I use .gitignore to ignore files that everybody is likely to see, like build products. I use .git/info/exclude to ignore stuff that only matters to me, like my private “test” subfolder.
    2
  12. In those days, it was believed you had to lock files when they were checked out, because if two people made changes to the same file, the world would end or something.
    1
  13. There is a potential issue where you add commits to your copy of a branch, and then try to push it to a common server, and that fails because somebody else has already pushed their own commits onto the head of that same branch.
    1
  14. We’ve heard of one-hit wonders, but Linus really knocked it for six not once, but twice: first with the Linux kernel, and then with Git.
    1