I’m glad you’ve found it useful. If you have any suggestions for improvements please let me know.

You’re welcome. I very happy that people find it useful! ❤️

Thanks a lot dude! Yeah, it’s a journey, but understanding internals is a very good start. It’s not strictly necessary but I personally I like knowing how tools that I use work under the hood.

Thank you so much for your kind words and support. I'm thrilled that you've enjoyed it. Your encouragement means a lot to me! ❤

Thanks. This means a lot to me!

You're welcome. I'm glad you've liked it :)

Thank you very much for the kind words!

Hi, thank you very much for leaving such comment. I’m glad to hear that you appreciate the focus on the important stuff. :-) Apologies for the late reply.

Thanks a lot! I’ll do my best to make sure future videos are even better.

Thank you!

Thanks a lot! ❤️

Thanks, I'm so glad that you've found it helpful!

Thank you for taking the time to comment Zebedee. I'm very happy to hear that you like my videos.

Thank you, and you’re welcome. I’m very happy to hear that you like my videos. I’ll do my best to keep and improve the quality.

Thank you Mina. I'm glad you've enjoyed it!

Thank you so much! :)

Thanks!

You're welcome! I'm glad you've liked it.

Thanks. Glad you liked it!

Thanks a lot Manick. Hope you’ll enjoy my future videos too!

Thanks a lot!

You’re welcome! Glad to hear you’ve enjoyed it.

You're welcome. Great to hear that!

You’re welcome. 🙂

Glad you've found it useful!

You’re welcome. I agree. Git is a good example for why data structures are important.

Thanks. That’s a great suggestion.

Glad you liked it!

You’re welcome! 🙂

Glad you've found it useful!

Glad it helped!

You're welcome! I'm glad you've liked it.

You’re welcome. I’m glad you liked it!

Rebase is useful for tidying up private branches before making things public. Once a branch is public, rebasing is going to annoy people who try to copy your branches.

@@lawrencedoliveiro9104 Indeed, projects I have contributed to usually want things rebased to the latest commit on the main public branch. They also prefer squashed commits, so your changes over multiple commits on your private branch appear as a single commit for merging to the main branch. I also like it this way, because it means I can mess around to my heart's content in my private branch until I have something I am ready to show the world, and any embrassing mistakes in the commit history of my private branch don't need to be part of the public history.

You’re welcome!

Thank you!

Glad you liked it! :)

Yes, that’s correct. The main eventually becomes F’ but only after the feature (using merge fast-forward). I made a mistake in the animation where I was focused on the desired outcome.

You’re welcome! 😀

Thank you :)

Thanks!

Thank you!

Thanks a lot for the kind words. I’m very happy to hear that you’ve liked it.

Thank you!

Thanks a lot :) Glad you've liked it!

Thank you for the comment. That’s great to hear. I have no doubt that you’ll end up using Git at some point in your career, and I’m glad to hear that you’ve found this video helpful.

I’m glad you’ve enjoyed it. Cheers!

Thank you. I’m really glad you think so ❤️

Thank you! Happy rebasing 😀

Thank you!

That makes sense, thanks.

I’m glad you’ve found it useful!

Thanks a lot!

Thanks a lot Michael! That sounds tough. Fortunately, I didn't have to deal with such problems :) I've only used SVN prior to Git, which wasn't great but acceptable.

Thanks a lot for the comment. Take the following with the grain of salt because I haven't validated if git does this, but since Git Trees are essentially Merkle Trees, this is probably how it works. If you want to compare two commits, this is essentially the same as comparing two git trees / merkle trees. Each git tree node has an ID, which is computed from its contents (other git trees or blobs). The same git trees will have exactly the same IDs, so comparing them is very fast. The problem is when two git trees don't have the same contents, then we have to compare the contents of both trees (again, note that we only compare the IDs of sub-trees and files). I think this is actually very fast in practice because we never need to compare the actual contents a file unless we know they are different in both trees. Eventually, we will identify the set of files whose content is different in each git tree, and we can run the diff tool only for these files. Above is a bit of a braindump, but hopefully it makes sense. Let me know if it doesn't though, and I'll try to elaborate.

Really glad it helped!

Thank you!

Thank you!

You’re welcome!

Thanks :) Actually, if I understand your approach correctly then it sounds like that is indeed the correct way to use rebase. In the video, I omitted the step where feature branch is rebased on the main branch. I think that has to happen and we can then use merge with fast-forward to update the main branch. I didn't omit this intentionally, it was an oversight.

Thanks. I might create a video that shows how git diff for a single file works. Thanks for the suggestion. I don't know if git does anything special to track renamed files. The renamed file will have the same content (unless the content was changed as well), so its ID will remain the same. However, the tree object containing the list of files will change.

Thank you for the comment. I'm glad it was helpful! :)

Thank you!

Thank you

Thanks a lot!

I think git does something to improve the storage of blobs, but it's not smart to realise that the 99% of the blob is the same. My guess is that this is probably optimized for text files rather than random binaries. I don't know if Git LFS does something though, but I'd expect it to have some kind of optimizations that work better for binaries. With that said, I don't know exactly what Git does, but here I've tested the above as follows: - Create an empty git project (its size is negligible) - Create a 1GB file with random data `dd if=/dev/urandom of=sample.txt bs=1G count=1` - Commit changes. The repo size is ~2GB. ~1GB for the blob and 1GB for the working directory. (see [1]) - Change 1 byte in the sample.txt file. - Commit the change. The repo size is ~2.58GB. (see [2] for inspecting the blob) - One more time. The repo size is 3.11GB. [1] ~/test (main) $ git ls-tree 60914ef 100644 blob 1d2579e731b4de097bda567f86bcf70d4c9fb4c6 sample.txt ~/test (main) $ ll -h ./.git/objects/1d/2579e731b4de097bda567f86bcf70d4c9fb4c6 -r--r--r-- 1 Nikola 197121 1.1G Oct 2 23:27 ./.git/objects/1d/2579e731b4de097bda567f86bcf70d4c9fb4c6 [2] ~/test (main) $ ll -h .git/objects/81/c9a65ac724cfcd7afaa1986609de53368ef2ae -r--r--r-- 1 Nikola 197121 543M Oct 2 23:21 .git/objects/81/c9a65ac724cfcd7afaa1986609de53368ef2ae

@@TechWithNikola That seems quite wasteful, but that could just be because it's optimized for speed, not storage size.

Yes, that sounds right to me. Minor correction: "after the common branch" -> "after the common commit"

Hvala! :-) Slazem se da bi bilo dobro, mada sam negde morao da presecem. Mozda napravim novi video o gitu u nekom trenutku. Da, preko merkle stabla mozemo da pronadjemo razlicite fajlove jako brzo. Diff izmedju dva fajla je baziran na LCSu (po linijama - Myers algorithm), mada mislim da ima par algoritama i kod gita je cini mi se to configurable.

Thank you. Yes, I will likely produce a follow up video on git, but maybe with more focus on network synchronisations. 7:24 gets me to recap so I couldn’t find what you are referring to, but my guess is that you mean metadata about blobs such as filename and metadata about commits? I have mentioned both in the video: - filenames are stored in tree objects - messages, author, etc are stored in commit objects Is this what you mean or did I misunderstand the comment?

Yes that was my question, I tried to go back and forth again but could not find where you mentioned these two details 😢, can you provide the timestamps?

Sure. I speak about filesnames being stored in git trees at 4:20 ukposts.info/have/v-deo/iqh5fpqYp7Bj0WQ.html Specifically, the sentence saying "tree solves the problem of not having a filename associated with a blob". There's also a tree visualization that shows filenames associated with blob object IDs. I talk about commits at 5:40 ukposts.info/have/v-deo/iqh5fpqYp7Bj0WQ.htmlsi=pYAahuiGe71jjSB_&t=338 I say that we store information about a single change into commits. Does this answer your question or is it maybe unclear in some way?

Okay thx but what about additional meta data of the filesystem like the bits for read write execute? I liked the summary you gave and I think it would have been perfect to add these details. Thx again, looking forward to more videos.

Good catch! Yes, it should say "previous: initial-prototype" I haven't experiment with hash collisions myself, but I think that git won't do anything about collisions locally. This answer might be helpful: stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob

Thank you!

Thank you ❤️

Thank you for the comment. That’s a good point. In practice, the feature branch would be updated first (using git rebase command), then the main branch would be moved forward (e.g. using git merge command). My focus was on the mechanics/idea of the rebase, and I forgot to include that step. Hopefully the explanation still makes sense.

Hi Luke, thanks for the question. I'll try to explain this by walking you through some examples. Let's start with looking at where the branch information is stored. If you go to any git repo, try to create a new branch called feat, i.e. using `git checkout -b feat`. This will create a new branch pointing to the current commit. Run `cat .git/refs/heads/feat` from the root of your repo to see the contents of this file - you should see the commit that the feat branch points to. You can even try to change the contents of this file manually, e.g. to point to some other commit of your choice, and the feat branch will be updated. > "I thought branches were a collection of commits unique to that branch" I wouldn't define a branch like this, but this statement has indirect truth to it. What I mean by this is that each commit stores a reference to the parent commit, which means that a single commit also represents a unique path from the root of the repo to this commit, which we can think of as a collection of commits. However, there is nothing unique about branches because you can create multiple branches that all point to the same commit (give it a try yourself using `git checkout -b `. > This is why two branches can take very different paths from master Sorry, I didn't understand this part. Two branches *can* take different paths because they can point to two different commits. Maybe the part that's confusing to you is how can two commits take diverging paths? This can happen by adding new commit to the same parent commit multiple times. For example, imagine you have checked out commit C1, then you make some changes and commit them as commit C2, which gives you a path C1

@@TechWithNikola thank you for taking the time to write out that super helpful response. I will need to chew on it for a bit and probably play around in Git Bash to fully comprehend some of the finer points, but this gives me a good jumping off point. Thanks again! Looking forward to more of your videos

A branch name points to just one commit-the latest commit on that branch. Each commit points back to its parent(s), and that’s how you trace the commit history, by going backwards. Parents do not point to their children, because then adding/removing children would change the content of the parent, which would in turn change the hash of that content. But that hash represents the identity of the parent object, so changing it is not allowed.

Commits are stored in the object database, same as blobs. I think it is a binary format, not text files. Note that the object database is just a bunch of files in git (in the .git/objects directory). I wouldn't say the format is similar to HTTP headers. I don't know the exact details of the binary format, but you can find out more here if you're curious: github.com/git/git/blob/d0e8084c65cbf949038ae4cc344ac2c2efd77415/commit.h#L26. You may need to trace how the commit struct is constructed to find out the serialization format. Branches are saved as files under ./git/refs/heads/. These are not symlinks. The file for the corresponding branch contains the commit ID it points to.

Agreed. Is there anything regarding the audio quality that I can improve?

​@TechWithNikola There's a very strong but very short reverberation in your audio recording. My guess is that the audio is being recorded in a room about the size of a closet. It was jarring to listen to when I first played it so I ended up skipping the video.

Thank you for the feedback. I don't hear it myself but it may be dependent on the audio device - I will look more into this. FWIW, the room is not the size of a closet, it's ~15 sqm, so I doubt that's the isuse.

Hi, yes it does. It would result in a merge conflict. If you watch the part on how cherry picking is implemented you’ll see that it uses the same algorithm as merging, which ensures that changes are not lost.

Спасибо!

Thanks for the suggestion. Yeah, that may have been better.

Thank you

Yes, thanks. That was a mistake in the animation that was pointed out in a few comments so far. You're right, main branch will point to d, feature branch will point to f' after `git rebase main`, then we have a final step to merge the main and the feature branches with `git merge` which simply apply the fast-forward merge and update main to point to f' as well. Regarding the: - e becomes e' and its father is d - f becomes f' and its father is e' e and f will remain unchanged, so I don't think it's accurate to say that e becomes e'. Do you mean e' will correspond to e (and f' to f)?

Hi Dario! I think the confusion comes from the fact that the object database is not a table. I use a table-like view to visualize the properties of the database, but in practice, the object database is just a bunch of files. The key is the filename (left column) while the object (right column) are the contents of the file. To answer your questions: > What does the 'Object' column contain? The actual object contents, as shown in 1:50? The "Object" column contains the actual object contents. > Is perhaps the Object Database composed of just one column and not two as shown? I tried to explain above, but let me know if it still doesn't make sense.

> Never mind, I've just googled it and found that there's also a filepaths reference store connected as though by a database primary key to the object store, and both the stores merely function like one database. Your graphics are only conceptual. Correct, graphics are only conceptual.

@@TechWithNikola Wow, you're quick! :) Thanks for the answers. The video is awesome, I'm still watching it.

Hi, thanks! I'm from Serbia :)

Hi Rafsan, FAT32 uses one index per folder which can reference around 65k files or folders (the actual number is more subtle because it depends on the length of the file/folder names, but this is a good approximation). Each folder has its own index, so you could store ~65k files/folders per folder. This means that you could have a much bigger number of folders in total by organizing them into subfolders, in a tree-like structure. You are right that there is an overall hard limit for the number of files/folders on FAT32 file system, but this number is much bigger than 65k, I think it's around ~250 million files.

You’re welcome!

Hi, thanks for the question. Your experiment produces the expected results, i.e. cherry-picking a single commit will add the *diff* from that commit and the parent commit, not the whole commit. This is why you’re seeing this behaviour even though commits are full snapshots. I have explained this in the video - have you seen the part that explains how cherry-picking works?

​​​@@TechWithNikola yes yes. Today I tried very hard and I found commit is a full snapshot. You are right about cherry-pick. Even when you Cherry-pick direct merge commit which have 2 parents, you have to specify using -m that which parent do you want to get diff from. NOTE : I create file_1 in master with first commit. file_2 - 2nd commit file_3 - 3rd commit file_4 - 4th commit file_5 - 5th commit Now 6th commit I changes some content in file_1. `git diff HEAD HEAD~1` I checked difference between latest commit and 2nd last latest. Even commit - 5th just only add file_5, It was showing file_1 content changed. That means the commit is full snapshot... in 5th commit ( full snapshot) the file_1 was as it is.. in 6th commit I changes file_1 content... And it will show everything where I am on 5th commit at that time to 6th commit full snapshots changes..even I didn't touched file_1 in my 5th commit. ( only file_5 added and rest of snapshot stays as it is) Wow man you are such a genius.

@@DhavalAhir10 that’s great. I’m glad that it all makes sense now!

Have you tried git-lfs.com/ ? I've used it for non-human-readable files and it works fine. This should work with any git GUI: git-scm.com/downloads/guis

Thank you for the comment. I don’t agree that the second part is “just a standard tutorial that doesn’t fit in”. How to generalize cherry-picks via merge is not something that is covered by standard tutorials. I agree that there are more topics that can be covered, such as the ones you’ve mentioned but also a lot more. There’s a tradeoff between having a very long and comprehensive video that covers all the details, and the one that covers core concepts but is easier to consume. Staging index and stashes, while important, are secondary features IMO. I agree that they can be covered but I don’t think that all topics have to be done in a single video. Diffing applied internally to save space is interesting on its own, but I don’t think it’s relevant enough to be in the same video as the object store. With that said, I would like to have a sequel to this video that covers other important details, such as how git syncs data over the network, etc. In any case, this is my view, which may be wrong, so I appreciate the feedback. Thank you for taking the time to leave the comment.

The terminology and the exact action depends on whether you're using Git, Mercurial, SVN, or maybe Microsoft TFS. Git doesn't have check-in command, so it doesn't make much sense to think about the difference between commit and check-in in Git. Commit pushes changes to the local repository in Git, and you have to use `git push` command to sends local changes to the server. In SVN, I think commit command sends changes to the server (unlike git or mercurial which stores the changes in the local repo), but I'm not 100% sure. In TFS, the `checkin` command[1] sends changes to the server. [1] learn.microsoft.com/en-us/azure/devops/repos/tfvc/checkin-command?view=azure-devops

Thanks. I’ll see what I can do. FWIW, I already use the Blue Yeti X.

Great! So the problem lies within the configuration of the effects you use and how you handling them.@@TechWithNikola

Hi Andreas, thank you for the feedback. I appreciate taking the time to comment. You are certainly right that git doesn't track changes in the sense that it has changesets (e.g. like mercurial). My intent at that point in the video was to talk about the ideas and abstractions, rather than implementation details, and I think all version control systems have a decent amount of overlap in the problems they are trying to solve. It's still true that Git tracks changes in "some sense". Maybe they are not represented as changes under the hood, but you could argue that this is an implementation detail. Some people may argue that it also doesn't store[1] full snapshots. Whether it's right to say that as an opening statement or not, I'm not sure if I'm being honest. Being very precise at every moment comes with tradeoffs. It can be beneficial to say a potentially imprecise statement if it introduces the listener to the ideas quicker. I think this is especially important when trying to explain how things work from the high-level. Doing the bottom-up approach would be more precise for sure, but most people (including myself) find it harder to grasp concepts that way. I'm curious to hear if you have a suggestion on what would be a better statement at that point in the video; that would be appreciated! [1] While git stores snapshots of some form, some people may argue that it's not complete because it won't copy the files that haven't changed. For example, the files that remained unchanged would be stored as a reference, but does that matter? The devil is in the details, so it all depends on the intent.

Thanks. Haha no, this is my first and only channel.

Is there anything specific that was confusing? Maybe I can elaborate in the comment?