After reading my blog, criezy generously suggested that I took time learning git commands and even discussed with him. Sev also repasted the git pro book, and suggested that the first 3 chapter would do. So basically, although I thought is was not a good idea to resolve something like this at the very first day of GSoC coding period, that’s what I did. Read the docs.
What’s amazing was it was actually useful. Very useful. Much effective than what I have expected. Probably because after finding out how to do it with the GUI, there is no pressure on me that I cannot commit something (although I would have to give every file a separate commit). It was also probably because it was the right time to read the git pro book. Compared to the me 2 months ago, it’s kind of different after 32 “
git add && git commit -m "GRIFFON: Commit message" && git push “es.
It’s astonishing how my understanding went from 1% to 90% (and imagine that I regarded that 1% of learning as some highly recommended material, and you would understand what I went through). As if the language the lecturer was speaking had changed. (From something like French to English, while I recognize like 150 vocabularies of the former language, and will only understand anything typed on the terminal, shown in the animation, or demonstrated non-verbally.)
Git is amazing in the way it is both simple and not easy at the same time. I feel git is something most people get only by playing with and studying for a period of time. That’s why it is not introduced to google docs or any other things. I wish we had that. No more “duplicate files”, “All changes saved to drive”, “Oh we have a conflict pick a version!”.
Below are some notes to what I have learned from git.
The funny thing is that what you “know” before and after you “really know” is the same. It feels dump yet magical as I look at what I type.
Git exists for this purpose
To manage files that are similar but not the same. To edit while keep tracking, separately or together, and unifying versions when we want to.
Existing files have this problem
There is only space to store the file content, but no one is responsible for tracking changes – git is responsible and accomplishes it by hashing and matching lines to detect change
commit – a change
branch – a series of changes. The current branch tracks new commits.
head – a pointer to the branch that is tracking new commits
switch – change the branch the head is pointing at. Your working directory and its content are changed to the lastest commit at that branch
merge – combine changes by manually resolving conflicts
rebase – change the base of a branch. Specify a branch A to be rebased and branch B to be rebased to. Starting from the place the the files’ content diverge, move branch A to following after branch B
merge and rebase are used for similar purposes but work differently. If you use merge you will need to resolve conflict. If you use rebase you will need to . If you rebase a commit that has been updated to the internet, things get screwed up.
(beginners can ignore these three for a while, just know that check-out is like switch because it’s often referred)
*check-out – everything in switch, but including checking out a commit. When you checkout a commit, nothing strange happens, but that it doesn’t belong to a branch. You can make a series of commits, just like in a branch. However, you cannot come back to the series of commits once you switch back to a real branch, and the commits are lost when a garbage collector comes by, unless you switch back in time, and created a branch (surely, check-out is not a bug, must be another killing feature)
*fast-forward – you have already done the merge/rebase, go to merged/rebased place
*tag – branch that doesn’t update once it is created (same comment as check-out)
remote copy – taylorzhancher/scummvm. Not to be confused with local copy (files on the computer)
origin – the default name of a remote copy (every copy is a remote copy) on the local copy
fetch – get the branches from the internet to local copy
pull – fetch then merge
upstream – the default name the main repository on the local copy
git config --global pull.rebase true make
git pull do fetch then rebase instead
Some questions to answer in the future
So what if we do a rebase, and go back to branch A, then do a merge? Does a fast forward happen?
Not clear with what is a change. How do you define two lines as the same? Is delete considered a change? If so, what if I propose a blank file to merge with a new one? What happens when I try to merge an unrelated file to a repository?
Good things take times
While studying, it was pretty irritating to see the time ticking, and nothing done except something referred as “the second quadrant activity” in The Seven Habits of Highly Effective People – Things that are important but not urgent, and are usually the long term things that counts the most but gets ignored.
For some reason, the feeling was especially prominent during the last chapter of git pro and the last half an hour of how git works. I wanted to tell myself it’s only a few minutes left, and still I had to rewatch or re-read it a few times because I kept losing my attention. Maybe the excitement of understanding documentation that I hardly comprehend before was wearing off, more likely because I can’t help thinking what to do next.
I do understand though, after taking and looking at the notes, that I have a lot to learn, even though it’s the basics, and I have put so much time in it. Happy developing.
Sev reviewed my code, so I have something to commit today without making progress on finding secret code to specifying GUI options on the sci engine. After publishing this post I will be typing command to my terminal and praying that they will work. Then I will make commits to fix the code, hopefully. (Actually no hope. Uggh!!)
Although I haven’t fully seen the impact of blockchain in anything else than crypto, here is a good example of hashing and tracking.
I think it’s just beautiful.