this is gold please continue with this content (merge, rebase, reset, remote repo's, how the comparison between files is working, detached HEAD, what was the number :) ....)
This is too good. There is no other video currently that explains these concepts in such a detailed yet refreshing way. Please keep doing these videos. Thanks a lot
As many have already stated, this series is brilliant. Thank you! Git is intensity powerful and ubiquitous but, with all of its weird and unique terminology, it can be hard to fully understand what's going on and to have confidence in my commands. This series is a huge help. Even just knowing exactly where to check for the changes I've made is a big confidence boost. If you create more videos in this format, my one bit of feedback for improvement would be to put a simple highlight square around either the terminal or the notes to show which side of the screen we should move our attention to. I watched most of this video concentrated solely on the terminal and didn't realise the notes had been updated with the pointers, etc. But really, great job. Thank you for your effort 👍🏼🙏🏼
Thank you so much for your kind and helpful response Pete! I am working on five more videos in this series, and I will take your input into account. I will try to highlight focus points when relevant. Thanks and please share these videos with others as well 🙏🏻
This is by far the best deep-dive videos on git. Precise, to the point, brilliant! Thank you. Please keep making such amazing videos, I have my notifications on :)
Wow, thanks so much for your kind words! I am working on more and will definitely add more. If you'd like me to cover something specific, please let me know :)
Thank you so much for your kind response! I've just shared the first video in the series about Merge & Rebase. I will also share a live lecture I gave about Git recently when I get the recording, so stay tuned :)
Dude just turned 4 git commands (git init add commit branch) into 5 pages of notes🤯. Felt like a linked list and pointers video more than git 😂 Awesome content❤
Excellent tutorial. I particularly like the style and the fact that you anticipate what questions the viewer might have. It's really useful to learn this, also when you just use git with 'porcelain' commands. For future videos it would e.g. be nice to explain what goes on when rebasing is done.
Question: In the diagram at 27:13 how can the second commit contain the full state of our files it it only references the tree object pointing to the second file we created? Shouldn't the tree object it references point to both our files (blobs) at this stage? Or did I miss something? 🙂
Omer, Your material is by far, the best I've seen on-line. so is your book. These videos should have had millions of views Did you stop making videos? it's been more than 7 months since you last uploaded anything...
Thank you so much Shubi! I haven't really stopped but I am currently very busy. I am creating content that will become videos though - every video requires quite a lot of preparation 😇 I will try to continue soon, please let me know if you have specific requests
Great explanation. After seeing 3 videos I'm missing some info. 1. Do the sha files contain the content of the file? 2 How is the file tree, as seen by say an editor get created when I chechout a branch? 3 Does git go and recreate the entire tree from the blobs? 4 what if two files have the same sha? Thanks!!
Hello there, thanks for your questions. 1. The blobs include the content of the file, yes. 2. The file tree is derived from the index file, which is populated based on the base commit. 3+4. Have you watched the video on Git Objects? I explain these topics there: ua-cam.com/video/MyvyqdQ3OjI/v-deo.html I hope this helps :)
can i ask you some questions for example when we commited index dont change? and what git does if i create file with the same content what means same hash or simply hash collision
Hey, of course you can ask :) When you commit - the commit object equals the state of the index (that is, the tree the commit is pointing to is the same), and the index doesn't change as a result of the commit operation. When you create a file with the same content you'll get the same blob sha - it's not a collision, it's a nice optimization if you think of it :) I hope this answered your questions
@@BriefVid This is literally the best video explaining git internals. After like searching video in youtube. Finally I understand! Also I have an idea for future video. Maybe explain what is hooks is? Because when we do git init. Its always there with a bunch of .sample file
I was searching for information about git basics and this is by far the best explained i've seen. Why was --cacheinfo used with 100644 ? u said your would explain on the comment section but could not find any reference :)
@diegoescobar79 - thank you so much for your kind reply, and also - thank you for your question! 100644 is a way of showing the file permissions, and specifically the value 100644 means that this is a regular file. Files can have different "modes" - some files can be executables (e.g., scripts, .exe), some files are symlinks, and others are "regular" (text) files. Each of these types are represented with a number, such as as 100644. Another example would be 120000, representing symbolic links. On Unix systems we use these permissions to give users and user groups different levels of access to certain files and directories. These types of permissions are not relevant in git, therefore git uses only a subset of the regular file permission from the usual POSIX types and modes (in octal, 12 for a symbolic link, 10 for a regular file, 04 for a directory) to which git adds 16 for Git links. For files, you’ll only ever see 100755 or 100644 (although 100664 is also technically possible); directories are 040000 (permissions are ignored), symbolic links 120000. I hope this clarifies things
Amazing video. One thing: in the end, did we leave the index file as it is, and still git figured out that index and master are same, content-wise, and hence git status shows no changes?
Thank you for your comment! In the end, Git sees that the tree object that the index is pointing to is the same as the one HEAD is pointing to. If you want to understand this technically, I recommend reading: git-scm.com/docs/index-format#_cache_tree
Very interesting video. I like how you build it up instead of abstractly speaking about the structure itself. With such a command of the internals of git, do you have any thoughts on what you see as the future of version control? For example, do you see the possibility of a semantic version control that works without the artificial boundary of a repo? For example, say you had the metadata in the .git folder itself encompassed as git objects. Instead of having triples in text files (which have no hash-based content addresses), you would have an object whose properties include those properties. Could you see the possibilities and opportunities that would be enabled if you were to be able to "git push/merge" entire graphs, regardless of relatively arbitrary "repo boundaries"? Have you ever considered this type of future version control, and how it would be able to "version" real-world things, e.g., gardens, plants, recipes, etc.?
Thank you for your kind words! Personally, I really want to see semantic diffs implemented into source control systems, though I think it's unlikely to happen. The basics (that is, algorithms :) ) have existed for years, yet everyone is so accustomed to using Git that they don't see a reason to change. Regarding your suggestion - I think it's interesting to consider, definitely. Just to note - Git doesn't necessarily store code. It can store anything digital - it's a versioned filesystem. I don't think a "repository" is such a huge constraint either, as you can work with subtrees when needed.
@@BriefVid ah hah! I got you! It was a bit of a sneaky question on my part... I have already been working on a "semantic version control" system for the past decade, accidentally reimplementing much of git's internals. The key to the **future** though is the assumption in your first statement about semantic diffs into **source control systems**. As you state, it's anything digital and we know that git was hyperoptimized for text specifically with source control in mind (he was after all looking for how to better version control his OS source). I however have been trying to simplify the complexity of multiple domain development. It has turned out that this "meta language" ends up looking very similar to a version control system. This does end up making a bit of sense, as you can consider git and its integration into devops evolution as a meta language that orchestrates heterogeneous code bases. Only recently (within the past year) did I start on the source control use case and I was searching for specifics on git internals because they seem to do something funky with the pack files at the binary level. For my dogfooding use case, I wanted to be able to simply add my projects' existing git repos' `.git` folders into my version control, so that if needed I could go back and look at logs, histories, etc. At first I was converting NodeJS `Buffer`s into a best-guess encoding and then returning to `Buffer`s and it was failing on just the `index` file. But even if I only use raw `Buffer`s with zero conversion, the git internal pack files get corrupted. So my kluge now is to just compress the `.git` folder and unzip it just once per "repo" initialization. ("Repo" in quotes because indeed I am doing away with the repo paradigm, which though you say wouldn't be a huge constraint, it's actually huge added layer of complexity when you don't have a root "single source of truth" river. You can think of it as like more granular version control timelines - say being able to import someone else's individual function or class, the key to which being largely the content addressing scheme). So hey, would you happen to know what they're doing with those pack files and why it would fail with just raw NodeJS `Buffer` `readfile`/`writefile` operations? Sorry for the sneaky question! Like you said, no one even **sees** a reason to change. But the metaverse ain't gonna be programmed without a new timeline composition framework (and not just for source control...think version controlling your gardens, individual plants, derivative metadata like videos...hey these YT videos even!)
Hey brief, really good explanations! This git internal series is awesome. Hope you will continue! For the curious, is there any documentation you based this series on so I can dive into it? thanks!
Hi Jeremy! I actually based it on a lot of resources - the git book, a few lectures, and my own experience, so it's hard for me to refer you to a specific location. I would recommend the git book for sure - git-scm.com/book/en/v2. I hope this helps!
Рік тому+1
Hi just a question, around 17 minute we have a tree object created and then we querry about type of an object using hash and knows it is a tree object, not a blob. How does git know this? Does it do some sort of unhashing? And then sees how output of this looks like? Or maybe it stores type in a hash somehow?
Hi @ZarkoTomicic, thanks for the question! Indeed I haven't covered this detail, perhaps I should create a short video about it too 🤔 It is not "unhashing" (which is, in theory, not possible). As I explained in the video - the hash is used as an index, so given the hash - you can get to the object itself. The object is compressed with `zlib` (same library used for `.zip` files). If you decompress ("unzip") the object file actually begins with the string "blob", "tree", or "commit" - signaling what type of object that is. For more info - read the section "Object Storage" here: git-scm.com/book/en/v2/Git-Internals-Git-Objects Indeed it could be a nice and short video to add :)
Рік тому+1
@@BriefVid thanks! So hashing creates an Id but content can not be recrested from hash. It seems I had a lapsus in undersranding, thinking that hash can be used to compress content of a file into 40 digit number lol.
Рік тому+1
@@BriefVid btw vreat videos on this subject. I started to work as sw developer two years ago st age 38, having never been any sort of programmer before and if I knew this series existed then, it would be of great use. But even now I think it is good to see it. I was a teacher before and from that persepctive I can tell you that these videos are near perfect when it comes to teaching and clarity. Thanks a lot.
@ thank you so much for your kind words! Please help my by sharing the content with more people :) Also, let me know if there are other topics you'd like me to cover
Does GIT place the whole content of a changed file even if only one line of it was changed? How does GIT calculate the difference between 2 commits? Does it retrieve the content of changed files from one commit and then retrieve the content of that same files from the other commit and runs something like GNU Diff?
Hi Nikita, thank you for your questions. Git does place the whole content of a file on every version. Git saves objects on disk in a format called a “loose” object format. Yet, Git packs up several of these objects into a single binary file called a “packfile” in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the git gc command manually, or if you push to a remote server. For more info about this: git-scm.com/book/en/v2/Git-Internals-Packfiles I hope this answers your question
Thank you for your question! 100644 is a way of showing the file permissions, and specifically the value 100644 means that this is a regular file. Files can have different "modes" - some files can be executables (e.g., scripts, .exe), some files are symlinks, and others are "regular" (text) files. Each of these types are represented with a number, such as as 100644. Another example would be 120000, representing symbolic links. On Unix systems we use these permissions to give users and user groups different levels of access to certain files and directories. These types of permissions are not relevant in git, therefore git uses only a subset of the regular file permission from the usual POSIX types and modes (in octal, 12 for a symbolic link, 10 for a regular file, 04 for a directory) to which git adds 16 for Git links. For files, you’ll only ever see 100755 or 100644 (although 100664 is also technically possible); directories are 040000 (permissions are ignored), symbolic links 120000. I hope this clarifies things
Thank you @Yu! Indeed, if a minor change is made, git will still create the entire blob. There is additional performance improvement (delta compression), but the entire blob is indeed created in the objects' database. I hope this is clear, feel free to ask more!
Note that a space after "awesome" is also included in the echo-ed and hashed string. Also, if you're on Unix-like system, remember to use DOS-style as a newline if you want to match the hash from the video. E.g. on my linux machine I get exactly the same hash as in video with: $ printf "Brief channel is awesome "|git hash-object --stdin 12afd3090092069b609372f6d279a82ce574bdae
@@BriefVid Yeah bro , right now I am doing work in git related work I need to know more clearly about gir graph like how to understand the git commit hash graph Like git graph extension in vscode
Hi , Need your help in one issue. After I follow the steps still git status cmd is not working PS D:\myrepo ew_repo> tree /f .git Folder PATH listing for volume Data Volume serial number is 000000FC F605:5E83 D:\MYREPO\NEW_REPO\.GIT │ HEAD │ ├───objects └───refs └───heads └───master PS D:\myrepo ew_repo> echo 'ref: refs/heads/master' > .\.git\HEAD PS D:\myrepo ew_repo> cat .\.git\HEAD ref: refs/heads/master PS D:\myrepo ew_repo> git status fatal: not a git repository (or any of the parent directories): .git PS D:\myrepo ew_repo> cat .\.git\HEAD ref: refs/heads/master PS D:\myrepo ew_repo> git status fatal: not a git repository (or any of the parent directories): .git PS D:\myrepo ew_repo>
Hi and thanks for your question. Can you please tell me the contents of `refs/heads/master`? By typing `cat .\git efs\heads\master`? Remember this should be a file pointing to the commit object, and not a folder
@@BriefVid Yes by mistake i created master as a folder. Now i deleted that folder. But still git status is not working PS D:\myrepo ew_repo> tree /f .\.git\ Folder PATH listing for volume Data Volume serial number is F605-5E83 D:\MYREPO\NEW_REPO\.GIT │ HEAD │ ├───objects └───refs └───heads PS D:\myrepo ew_repo> git status fatal: not a git repository (or any of the parent directories): .git PS D:\myrepo ew_repo>
@@SanjayKumar-fp5xu Well you still need `master` to be a file :) It needs to include the hash of the commit object you created. So echo > .git efs\heads\master Please let me know if that works :)
@@SanjayKumar-fp5xu same issue, you ever solve this? I follow step by step but his says its a repo and mine does not...I wonder if this is a versioning issue or what
this is gold
please continue with this content
(merge, rebase, reset, remote repo's, how the comparison between files is working, detached HEAD, what was the number :) ....)
Thank you Oren, I'll do my best 💪🏻
Please spread the word and share these videos if you find them helpful.
This is too good. There is no other video currently that explains these concepts in such a detailed yet refreshing way. Please keep doing these videos. Thanks a lot
Thanks a lot Ketki! It's very encouraging to get such responses! I do plan on continuing :)
Almost in tears watching this unfold.. so good.
Will recommend to others
Thank you!!! That's much appreciated 🙏🏻
Wow! Already, after just 4 videos, this is turning out to be the best series of videos explaining git that I've seen to far! Great job!! 🙂
Wow, thanks!
As many have already stated, this series is brilliant. Thank you! Git is intensity powerful and ubiquitous but, with all of its weird and unique terminology, it can be hard to fully understand what's going on and to have confidence in my commands. This series is a huge help. Even just knowing exactly where to check for the changes I've made is a big confidence boost.
If you create more videos in this format, my one bit of feedback for improvement would be to put a simple highlight square around either the terminal or the notes to show which side of the screen we should move our attention to. I watched most of this video concentrated solely on the terminal and didn't realise the notes had been updated with the pointers, etc.
But really, great job. Thank you for your effort 👍🏼🙏🏼
Thank you so much for your kind and helpful response Pete!
I am working on five more videos in this series, and I will take your input into account. I will try to highlight focus points when relevant.
Thanks and please share these videos with others as well 🙏🏻
This is by far the best deep-dive videos on git. Precise, to the point, brilliant!
Thank you.
Please keep making such amazing videos, I have my notifications on :)
Wow, thanks so much for your kind words!
I am working on more and will definitely add more. If you'd like me to cover something specific, please let me know :)
Hands down this is by far the best explanation of git. Thank you so much.
Wow, thanks for the warm comment! I am working on a series of five Git videos that I will release soon, say tuned 😎
This was the best explanation about git that I have seen so far :) Congrats
Wow, thanks! I'm glad you found it useful :)
Pure gold. You are an amazing guru! "Brief channel is very 'AWESOME' !" :))
Thanks! 😃
Absolutely BRILLIANT! Thank you so much! I've already shared it and am impatiently looking forward to the next episodes about merge, rebase, etc...
Thank you so much for your kind response!
I've just shared the first video in the series about Merge & Rebase.
I will also share a live lecture I gave about Git recently when I get the recording, so stay tuned :)
New subscriber here!!! HIGH QUALITY content!!! thank you very much!
Thank you so much for your kind response!
Very well structured and easy to follow guide, thank you
Glad it was helpful! Thank you for your kind comment!
Best content I found about git internals. Thank you for the effort.
Wow, thank you for your kind comment!
Your videos on Git are awesome. Such a simple explanation. Thanks for making these videos.
Thank you for your kind reply!
By far best tutorial on UA-cam.
Thank you Doron! Please help me spread the word 🙏🏻
Excellent content! One of the best series on git I've seen around.
Thank you so much James! I'm glad you liked it!
This is super @Brief. Please help putting more to this. Great to have someone actually putting effort on something that is ignored by all.
Thank you for your kind response Piyush! I will indeed be putting more to this in the upcoming months.
The best tutorial on git which I had seen, Tanks!
Wow, thanks Deny! What a great compliment 🙏🏻
Dude just turned 4 git commands (git init add commit branch) into 5 pages of notes🤯.
Felt like a linked list and pointers video more than git 😂
Awesome content❤
Thanks a lot for your kind comment 🙏🏻 Indeed, when you go deep things feel a bit different 😅
Excellent tutorial. I particularly like the style and the fact that you anticipate what questions the viewer might have. It's really useful to learn this, also when you just use git with 'porcelain' commands. For future videos it would e.g. be nice to explain what goes on when rebasing is done.
Glad it was helpful! And thanks a lot for the comment.
I will take this into account and create a video about rebasing in the future 💪🏻
I generally do not subscribe or comment, but your content compelled me to do so. Thanks brief for briefing such a wide concept !!
Thank you for your kind response Waqas! I appreciate it a lot!
+1
Damn, this is so good. Thank You Bro, I actually understood git under the hood !
Thank you for your kind words!
You deserve way more subscribers dude! Thank you for an amazing content
I appreciate that! Thank you for the kind comment and please help me share the word
We need more videos in this git series, this were amazing
Thank you so much Rahul! I will try to continue soon, please let me know if you have specific requests
awesome work 🔥🔥
Thanks @SUMEDH! 🔥
Question: In the diagram at 27:13 how can the second commit contain the full state of our files it it only references the tree object pointing to the second file we created? Shouldn't the tree object it references point to both our files (blobs) at this stage? Or did I miss something? 🙂
Hey there, 27:13 is the length of the video, so I guess you meant a different timestamp? :)
Wow!!!! I really appreciate the work.
It is really insightful, Keep the good work.
Thanks a lot Chandan! I do plan on continuing :)
This was so SO good, really helps with my assignment, and also just glad I understand it more deeply
Thank you very much!
super detailed and helpful, thanks a ton :)
Thank you for the nice comment!
Excellent tutorial 🙏🏻👍🏻
Thank you 🙌
Omer, Your material is by far, the best I've seen on-line. so is your book. These videos should have had millions of views
Did you stop making videos? it's been more than 7 months since you last uploaded anything...
Thank you so much Shubi!
I haven't really stopped but I am currently very busy. I am creating content that will become videos though - every video requires quite a lot of preparation 😇 I will try to continue soon, please let me know if you have specific requests
That is an awesome video and channel. Thank you! Looking forward to more "internals" topics.
Thank you Andrey! I'm working on a video about rewriting history and practical usages for it. Stay tuned :)
hi teacher, can i ask you one question ? when i followed your instruction at 15:12, my git status still has red color ( modified: brief.txt)
Hi I'm back, The cause of the problem above when I used Git in WSL. When using Git in window it worked perfectly
Hey, thank you for letting me know the problem was resolved. You can also see my talk in NYC where I do the same on WSL :)
Amazing explanation!
Thank you for this kind comment 🙏🏻
Amazing Video!!! Loved it!
Thanks so much!!
Super clear, thanks a lot!
Thank you for your kind comment
Why does he not have a billion subs , the content is fire dude . And what was the meaning of 100644 by the way?
Thank you for your kind response!
This page explain this very well:
koenwoortman.com/git-what-is-create-mode-100644/
Great explanation. After seeing 3 videos I'm missing some info. 1. Do the sha files contain the content of the file? 2 How is the file tree, as seen by say an editor get created when I chechout a branch? 3 Does git go and recreate the entire tree from the blobs? 4 what if two files have the same sha? Thanks!!
Hello there, thanks for your questions.
1. The blobs include the content of the file, yes.
2. The file tree is derived from the index file, which is populated based on the base commit.
3+4.
Have you watched the video on Git Objects? I explain these topics there:
ua-cam.com/video/MyvyqdQ3OjI/v-deo.html
I hope this helps :)
honestly this is the best!
Thanks a lot for your kind words!
Please let me know if there are other topics you'd like me to cover
can i ask you some questions for example when we commited index dont change? and what git does if i create file with the same content what means same hash or simply hash collision
Hey, of course you can ask :)
When you commit - the commit object equals the state of the index (that is, the tree the commit is pointing to is the same), and the index doesn't change as a result of the commit operation.
When you create a file with the same content you'll get the same blob sha - it's not a collision, it's a nice optimization if you think of it :)
I hope this answered your questions
You're doing god's work right here!
Thank you so much 🙏🏻🙏🏻
I cant wait for the next video!
Thanks Barra, I'm working on it :)
@@BriefVid This is literally the best video explaining git internals. After like searching video in youtube. Finally I understand! Also I have an idea for future video. Maybe explain what is hooks is? Because when we do git init. Its always there with a bunch of .sample file
I was searching for information about git basics and this is by far the best explained i've seen. Why was --cacheinfo used with 100644 ? u said your would explain on the comment section but could not find any reference :)
@diegoescobar79 - thank you so much for your kind reply, and also - thank you for your question!
100644 is a way of showing the file permissions, and specifically the value 100644 means that this is a regular file.
Files can have different "modes" - some files can be executables (e.g., scripts, .exe), some files are symlinks, and others are "regular" (text) files. Each of these types are represented with a number, such as as 100644. Another example would be 120000, representing symbolic links.
On Unix systems we use these permissions to give users and user groups different levels of access to certain files and directories. These types of permissions are not relevant in git, therefore git uses only a subset of the regular file permission from the usual POSIX types and modes (in octal, 12 for a symbolic link, 10 for a regular file, 04 for a directory) to which git adds 16 for Git links. For files, you’ll only ever see 100755 or 100644 (although 100664 is also technically possible); directories are 040000 (permissions are ignored), symbolic links 120000.
I hope this clarifies things
@@BriefVid Thanks for the complete answer! It did clarified. Thanks again for taking the time
Amazing video. One thing: in the end, did we leave the index file as it is, and still git figured out that index and master are same, content-wise, and hence git status shows no changes?
Thank you for your comment!
In the end, Git sees that the tree object that the index is pointing to is the same as the one HEAD is pointing to. If you want to understand this technically, I recommend reading:
git-scm.com/docs/index-format#_cache_tree
This is fantastic work.. Thank you for sharing.
Thanks a lot for this kind feedback Russell!
Very interesting video. I like how you build it up instead of abstractly speaking about the structure itself. With such a command of the internals of git, do you have any thoughts on what you see as the future of version control? For example, do you see the possibility of a semantic version control that works without the artificial boundary of a repo?
For example, say you had the metadata in the .git folder itself encompassed as git objects. Instead of having triples in text files (which have no hash-based content addresses), you would have an object whose properties include those properties. Could you see the possibilities and opportunities that would be enabled if you were to be able to "git push/merge" entire graphs, regardless of relatively arbitrary "repo boundaries"? Have you ever considered this type of future version control, and how it would be able to "version" real-world things, e.g., gardens, plants, recipes, etc.?
Thank you for your kind words!
Personally, I really want to see semantic diffs implemented into source control systems, though I think it's unlikely to happen. The basics (that is, algorithms :) ) have existed for years, yet everyone is so accustomed to using Git that they don't see a reason to change.
Regarding your suggestion - I think it's interesting to consider, definitely. Just to note - Git doesn't necessarily store code. It can store anything digital - it's a versioned filesystem. I don't think a "repository" is such a huge constraint either, as you can work with subtrees when needed.
@@BriefVid ah hah! I got you! It was a bit of a sneaky question on my part...
I have already been working on a "semantic version control" system for the past decade, accidentally reimplementing much of git's internals. The key to the **future** though is the assumption in your first statement about semantic diffs into **source control systems**. As you state, it's anything digital and we know that git was hyperoptimized for text specifically with source control in mind (he was after all looking for how to better version control his OS source). I however have been trying to simplify the complexity of multiple domain development. It has turned out that this "meta language" ends up looking very similar to a version control system. This does end up making a bit of sense, as you can consider git and its integration into devops evolution as a meta language that orchestrates heterogeneous code bases.
Only recently (within the past year) did I start on the source control use case and I was searching for specifics on git internals because they seem to do something funky with the pack files at the binary level. For my dogfooding use case, I wanted to be able to simply add my projects' existing git repos' `.git` folders into my version control, so that if needed I could go back and look at logs, histories, etc. At first I was converting NodeJS `Buffer`s into a best-guess encoding and then returning to `Buffer`s and it was failing on just the `index` file. But even if I only use raw `Buffer`s with zero conversion, the git internal pack files get corrupted. So my kluge now is to just compress the `.git` folder and unzip it just once per "repo" initialization. ("Repo" in quotes because indeed I am doing away with the repo paradigm, which though you say wouldn't be a huge constraint, it's actually huge added layer of complexity when you don't have a root "single source of truth" river. You can think of it as like more granular version control timelines - say being able to import someone else's individual function or class, the key to which being largely the content addressing scheme).
So hey, would you happen to know what they're doing with those pack files and why it would fail with just raw NodeJS `Buffer` `readfile`/`writefile` operations?
Sorry for the sneaky question! Like you said, no one even **sees** a reason to change. But the metaverse ain't gonna be programmed without a new timeline composition framework (and not just for source control...think version controlling your gardens, individual plants, derivative metadata like videos...hey these YT videos even!)
Hey brief, really good explanations! This git internal series is awesome. Hope you will continue! For the curious, is there any documentation you based this series on so I can dive into it? thanks!
Hi Jeremy! I actually based it on a lot of resources - the git book, a few lectures, and my own experience, so it's hard for me to refer you to a specific location. I would recommend the git book for sure - git-scm.com/book/en/v2.
I hope this helps!
Hi just a question, around 17 minute we have a tree object created and then we querry about type of an object using hash and knows it is a tree object, not a blob. How does git know this? Does it do some sort of unhashing? And then sees how output of this looks like? Or maybe it stores type in a hash somehow?
Hi @ZarkoTomicic, thanks for the question!
Indeed I haven't covered this detail, perhaps I should create a short video about it too 🤔
It is not "unhashing" (which is, in theory, not possible).
As I explained in the video - the hash is used as an index, so given the hash - you can get to the object itself. The object is compressed with `zlib` (same library used for `.zip` files).
If you decompress ("unzip") the object file actually begins with the string "blob", "tree", or "commit" - signaling what type of object that is.
For more info - read the section "Object Storage" here:
git-scm.com/book/en/v2/Git-Internals-Git-Objects
Indeed it could be a nice and short video to add :)
@@BriefVid thanks! So hashing creates an Id but content can not be recrested from hash. It seems I had a lapsus in undersranding, thinking that hash can be used to compress content of a file into 40 digit number lol.
@@BriefVid btw vreat videos on this subject. I started to work as sw developer two years ago st age 38, having never been any sort of programmer before and if I knew this series existed then, it would be of great use. But even now I think it is good to see it. I was a teacher before and from that persepctive I can tell you that these videos are near perfect when it comes to teaching and clarity. Thanks a lot.
@ Indeed, I am glad we clarified that :)
@ thank you so much for your kind words! Please help my by sharing the content with more people :) Also, let me know if there are other topics you'd like me to cover
For me this video was insight! Thank you so much, You are teacher from god!
Wow, thank you for your kind feedback!
Does GIT place the whole content of a changed file even if only one line of it was changed? How does GIT calculate the difference between 2 commits? Does it retrieve the content of changed files from one commit and then retrieve the content of that same files from the other commit and runs something like GNU Diff?
Hi Nikita, thank you for your questions.
Git does place the whole content of a file on every version. Git saves objects on disk in a format called a “loose” object format. Yet, Git packs up several of these objects into a single binary file called a “packfile” in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the git gc command manually, or if you push to a remote server.
For more info about this:
git-scm.com/book/en/v2/Git-Internals-Packfiles
I hope this answers your question
When is the next video coming up...!! These are really good.
Thanks a lot for this kind feedback Vijay! I will try to post more videos soon. Please let me know if you have specific requests
Excellent
Thank you so much 😀
Awesome fantastic excellent ... 🤩
Thank you so much 😀
So what's the deal with --cacheinfo 100644? What is it used for? Is that number special in any way? Why does git need it?
Thank you for your question!
100644 is a way of showing the file permissions, and specifically the value 100644 means that this is a regular file.
Files can have different "modes" - some files can be executables (e.g., scripts, .exe), some files are symlinks, and others are "regular" (text) files. Each of these types are represented with a number, such as as 100644. Another example would be 120000, representing symbolic links.
On Unix systems we use these permissions to give users and user groups different levels of access to certain files and directories. These types of permissions are not relevant in git, therefore git uses only a subset of the regular file permission from the usual POSIX types and modes (in octal, 12 for a symbolic link, 10 for a regular file, 04 for a directory) to which git adds 16 for Git links. For files, you’ll only ever see 100755 or 100644 (although 100664 is also technically possible); directories are 040000 (permissions are ignored), symbolic links 120000.
I hope this clarifies things
@@BriefVid it does thanks! I was aware of permissions but only in the 'rwx' form
so the larger number confused me
Great video. If a minor change is made on a large file, will git add still create the entire blob?
Thank you @Yu!
Indeed, if a minor change is made, git will still create the entire blob. There is additional performance improvement (delta compression), but the entire blob is indeed created in the objects' database. I hope this is clear, feel free to ask more!
@@BriefVid Understood. Thanks.
wow! thanks a lot
You're welcome! Thanks for your comment :)
Amazing, thanks.
Thank you for your kind response!
i got a different hash after creating the same blob "Brief channel is awesome" and I have no idea why...
Hi Noah, would you mind sharing a screenshot?
Note that a space after "awesome" is also included in the echo-ed and hashed string. Also, if you're on Unix-like system, remember to use DOS-style
as a newline if you want to match the hash from the video. E.g. on my linux machine I get exactly the same hash as in video with:
$ printf "Brief channel is awesome
"|git hash-object --stdin
12afd3090092069b609372f6d279a82ce574bdae
bro how to draw work graph using git commit hash
teach how to fetch the hash and using that to create a work graph
I'm sorry, I didn't understand what you mean. Can you please explain the question?
@@BriefVid
Yeah bro , right now I am doing work in git related work I need to know more clearly about gir graph like how to understand the git commit hash graph
Like git graph extension in vscode
@@kthamim7552 did you watch the Git Objects video? I believe it will get you what you're looking for :)
wow
Thank you 😇
Hi , Need your help in one issue. After I follow the steps still git status cmd is not working
PS D:\myrepo
ew_repo> tree /f .git
Folder PATH listing for volume Data
Volume serial number is 000000FC F605:5E83
D:\MYREPO\NEW_REPO\.GIT
│ HEAD
│
├───objects
└───refs
└───heads
└───master
PS D:\myrepo
ew_repo> echo 'ref: refs/heads/master' > .\.git\HEAD
PS D:\myrepo
ew_repo> cat .\.git\HEAD
ref: refs/heads/master
PS D:\myrepo
ew_repo> git status
fatal: not a git repository (or any of the parent directories): .git
PS D:\myrepo
ew_repo> cat .\.git\HEAD
ref: refs/heads/master
PS D:\myrepo
ew_repo> git status
fatal: not a git repository (or any of the parent directories): .git
PS D:\myrepo
ew_repo>
Hi and thanks for your question.
Can you please tell me the contents of `refs/heads/master`? By typing `cat .\git
efs\heads\master`?
Remember this should be a file pointing to the commit object, and not a folder
@@BriefVid Yes by mistake i created master as a folder. Now i deleted that folder.
But still git status is not working
PS D:\myrepo
ew_repo> tree /f .\.git\
Folder PATH listing for volume Data
Volume serial number is F605-5E83
D:\MYREPO\NEW_REPO\.GIT
│ HEAD
│
├───objects
└───refs
└───heads
PS D:\myrepo
ew_repo> git status
fatal: not a git repository (or any of the parent directories): .git
PS D:\myrepo
ew_repo>
@@SanjayKumar-fp5xu Well you still need `master` to be a file :) It needs to include the hash of the commit object you created. So echo > .git
efs\heads\master
Please let me know if that works :)
@@SanjayKumar-fp5xu same issue, you ever solve this? I follow step by step but his says its a repo and mine does not...I wonder if this is a versioning issue or what
You cannot use the git-hash method either unless it's ALREADY git repo...so b/c it's not a repo I can't use git-hash...: (