This part is to make it relatable for people and to communicate the purpose of the talk.
- Everyone struggles with git in the beginning. This xkcd comic: https://xkcd.com/1597/ My personal story as an example goes here.
- With all the other tools you get better with experience. You just learn its concepts one by one. not with git. git terminology looks like it's about space rockets.
- A joke about hilariously cryptic git error messages. I will share my experience: learning commands and going through "git recipies" and stackoverflow examples only got me even more confused.
- There are competing file version systems including the one used by the overwhelming majority of people: folders with descriptive names. And its good enough in so many cases.
- At that time I was asking myself: what does git contribute that justifies all this complexity? Why is it adopted so widely? (this talk is about attempting to answer this question)
This part is about the key data structure behind git. And why understanding it is the best way to become good with git.
- I struggled with git until I learned the key ideas behind it. That is, the key data structure used by git (the object store, I am going to avoid using this term and other fancy terminology as much as possible). Then everything came into its place and it was easy to become comfortable with git. I believe that learning it is the quickest way to become very good with git very quick.
- (I am worryied that the talk can get too abstract at this point so so I introduce a specific example of a problem we want to fix). A sample problem case: we want to rebase a commit while using the file versions solely from the feature branch instead of merging them. How do we do that? Learning the ideas behind git will point us towards an obvious solution right away.
- Now we have 3 more technical slides. They may be a little bit too dense but if we plough through them we will understand all there is to understand about git.
- Lets imagine we are designing the CVS. Identical files can belong to different versions so we need to store them by content. Lets introduce an object store: files with the hash of their content as the filenames. I will show that git does exactly that with a simple terminal example.
- Specific version is a list of filenames and their hashes as links. Where can we store them? Lets store them just like all other files in the same object store! A short demo in the cli to show that git does exactly that.
- Commits have messages and file lists and they are just text files too! they are stored in the same way in the object store. A cli demonstration.
- If you are still with me, congrats! That is all there is to understand about git!We made it, yay. The branches are just pointers to the head commit. Literally just text files with the commit's hash.
- All the other features we assosiate git with are built on this one data structure. Branches, diffs, merging scripts, remote git repos are scripts built around it.
- Quick summary: I think git has a beautiful heart (the choice of powerful algorithms) and a somewhat confusing and inconsistent interface [I want to communicate here that git is not that elaborate pinnacle of some deep philosophy and should not be that intimidating]. Maybe will talk about gits origins, Linus Torvalds and all that.
These points are illustrated with the use of the following git commands:
# saving a git object
echo 'blah-blah' | git hash-object -w --stdin
# decoding any git object
git cat-file -p [blob|tree|commit]Here we go through some practical examples. This is used as an excuse to introduce the most useful of the less known commands
- Both
--softand--hardgit resets - Browsing stuff:
git log,git reflog,git show - git cherry-pick
Let's practice!
- Let's create a commit that is a the merge of the two other commits and the content is from the third one
- Investigating a file history via cli
- Let's do what rebase command does manually.
- Maybe make a commit with fifty parents? :)
Also, a discussion on tools people use for help with git