Amazing! Most tutorials just talk about commits and often omits showing what happens in the working tree and the index. This is exactly the tutorial I was missing to understand the whole picture. Many thanks for putting together this great video!
Fantastic videos! Putting the command line side-by-side with the graphical model is just what I needed. A lot of tutorials I've seen neglect the fact that seeing two levels of abstraction side-by-side is a huge boost to comprehension.
Thanks @NirArad! I recently replied to another viewer about the difference here between using `git reset --soft` and my usage of `git reset --hard`. You are right of course - just notice that a longer explanation is there :)
Love the side by side with whiteboard and cli. Really well thought out animations and slow explanations. The magic is dissolving! Can’t wait to see how rebasing and other “complex” concepts come into play.
Hi! Great video! In your demonstration of resetting the main (minute 20) you used reset hard. Can you please explain why? I thought you would use reset soft since you still wanted the file to exist in the index for branch "features_branch" to point to it.
Hi and thanks for your question. I am not sure which example you are referring to exactly, but sometimes it's just a matter of what's more convenient. There are times where it's pretty much equivalent, as in most of the examples in this video - where I just rewrite the file. That is, if you rewrite the file anyway, it doesn't really matter whether it exists in the index. I am not 100% sure I understood your question correctly though. If I reset main, I change the pointer of main, and the current index. This doesn't affect `feature_branch` in any way. Please clarify your question if I haven't answered it.
@@BriefVid Thanks for answering so quick! I'll try to explain. Referring to the example that starts roughly at minute 19, You first created a "feature branch" and it points to commit 3. And then you have done a hard reset for head to point to 2.4. We said that hard reset erases the commit from all three stages. but we still want that cause now the "feature branch is pointing to that commit". Does hard reset behave like soft in this case because there is another branch pointing to that commit (commit 3)? Please Lmk if I'm still not clear. Thanks again
@@talyawertenteil8300 you are very welcome and I hope I was now able to understand you correctly. When using "git reset --hard" we don't erase any commit objects. What we do is move the pointer of HEAD ("soft stage"), and then also modify the staging area ("mixed" stage) and the working dir ("hard" stage). The original commit, where HEAD had pointed to before we issued the the "git reset" command, remains in Git's object database. If it was reachable from another branch - it still is. If it was reachable from another commit - it still is. If it is not reachable, it remains in the internal database of objects until it may be pruned in the future. I hope I was able to answer the question, please let me know if I missed something :)
I didn't get it. Why are the files that just have been commited are still in the staging area after the commit? The staging area should be clear / empty after the commit. Am I right? 🤔
Hi and thanks for your question. After the commit, the staging area "equals" the state of HEAD. It is confusing, as "git status" shows the DIFFERENCE between the states to show you what's most important, but if you think about the tree object that the index reprenesents, it would be the same as of HEAD after commiting, as "Commit" basically tells Git - "please use the state of the index and create a new Commit object with that state". I hope this is clear, please let me know if you have additional questions.
Thank you for your encouraging comment @Alfons. I am now focused on git internals for a bit, but I promise to be back to more networking videos soon 🙏🏻
For the problem at 18:50 I solved it this way: git branch new_feature git update-ref refs/heads/main Is there any drawback doing it this way ? Now that I think about it, I don't see any difference between "git reset --soft" and "git update-ref" other than the fact that "git reset" lets you use relative commits like HEAD~N Thanks.
Thank you for your comment. Indeed you are correct, this is a valid way. I wanted to explain `git reset` and its different switches so I demonstrated with this command. Regarding differences - `git reset --soft` doesn't actually create the commit, meaning you can then change your staging area before committing. If you don't want to change anything, then indeed your approach is practically the same. I hope this helps!
Рік тому+1
Just to comment a bit here, so you defined a working tree as any directory that has a git repo in it, then you create a directory using git init and you call it my_repo. Would it maybe be better to call it working_tree?
Thank you for the question. When I use `git init` I create a repository. The working tree is the currect state of this repo on my filesystem. It is true that in any given time, the contents of this folder ("my_repo") actually represent the working tree, but that is true for any repo - so we usually name the folder as the name of the repo. I hope this makes sense :)
Thank you so much! I don't want to promise, but I will work on it really soon and try to address requests I get from the comments here as well. Please help me by sharing these videos so more people know about them 🙏🏻
With reset soft, your changes (2.txt) should be in staging. With mixed, your changes (2.txt) should not be in staging but remain in your working tree. With hard, your changes (2.txt) should not exist at all in staging or the working tree. To undo your previous commit so you can change the commit or message, use 'soft' so that you keep your files and keep them in staging. You could also use 'mixed', but then you have to re-add the files to staging.
Great video as always. First, it will be great if you can cover reflog later in the series, and use reset to get back to a previous state. Perhaps explain a little bit like how to reset a rebase. Secondly, you can think about doing a "tutorial" type of video, where you propose the current and desired state, then provide your solution. That would be a very good exercise to practice the Git skills.
Thank you @Yu Sun! I like your suggestions. I will indeed include `reflog` in the next part then 👍🏻 I also like your "exercise" suggestion, and will try to incorporate it in the next part. Please help me by sharing these videos so more people know about them!
Hi Henry, thanks for your question! They remain in the internal object database, until they are scruned by git's garbage collection mechanism. You can read about it here: git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery
Amazing! Most tutorials just talk about commits and often omits showing what happens in the working tree and the index. This is exactly the tutorial I was missing to understand the whole picture. Many thanks for putting together this great video!
Glad it was helpful! Thanks for your kind words 🙏🏻🙏🏻
Fantastic videos! Putting the command line side-by-side with the graphical model is just what I needed. A lot of tutorials I've seen neglect the fact that seeing two levels of abstraction side-by-side is a huge boost to comprehension.
Thank you so much @Frank! I will be sure to create more videos of this style!
The best git tutorial out there! Thank you so much!!
Thank you for your kind comment, it really motivates me to keep creating more content 🙏🏻
Now, I can say I can confidently mange git history and really resolve commit related problems in git. Thanks for the gold mine🥇
Thank you so much for your kind words!
Excellent content!
Thank you so much Paul! If there's anything specific you'd like to see me cover, please let me know 🙏🏻
Awesome series man. Recommending it to all my developer colleagues. Go get a nice coffee!
Wow, thank you so much! Can I ask how you found the series?
Thanks!
Wow, thank you! 👏🏻🙏🏻
Excellent videos, thank you!
I want to point out that at 19:20 in the video, a 'git reset --soft' would have worked just as well.
Thanks @NirArad! I recently replied to another viewer about the difference here between using `git reset --soft` and my usage of `git reset --hard`.
You are right of course - just notice that a longer explanation is there :)
Very well Explained with Pictures.. Can not wait for Part-2
Thank you @subba! I will work on the next part soon :)
Love the side by side with whiteboard and cli. Really well thought out animations and slow explanations. The magic is dissolving! Can’t wait to see how rebasing and other “complex” concepts come into play.
Thanks so much @Tyler! I will indeed work on additional videos soon.
Great to see a new video come out! ;)
Thank you @Stanislav! Please subscribe so you get notified on the new ones, I am working on additional videos 🙏🏻
Well Explained, can't wait for the next part !!!
Thank you @High spparow! I will work on the next part soon :)
Bro your GIT series and this one too is just great. Keep up this good work man!
Thank you so much! Pleaes help me by spreading the word to more people p🙏🏻
@@BriefVid Sure
Amazing video!
Thanks!
Awesome fantastic excellent ... 🤩
Thank you so much 😀
Please keep these tutorials going!! Totally awesome resource
Thank you so much! I am working on new videos, please subscribe so you get notified when they are released :)
@@BriefVid i definitely did! Just wondering what software do u use to animate?
Thanks for creating these videos! I'm looking forward to the next one :)
Thank you @Jorge! I am working on the next one. In the meantime, please subscribe :)
Awesome fantastic excellent :)
Thank you so much Neeraj! Please subscribe 🙏🏻
Hi! Great video!
In your demonstration of resetting the main (minute 20) you used reset hard.
Can you please explain why?
I thought you would use reset soft since you still wanted the file to exist in the index for branch "features_branch" to point to it.
Hi and thanks for your question.
I am not sure which example you are referring to exactly, but sometimes it's just a matter of what's more convenient. There are times where it's pretty much equivalent, as in most of the examples in this video - where I just rewrite the file. That is, if you rewrite the file anyway, it doesn't really matter whether it exists in the index.
I am not 100% sure I understood your question correctly though.
If I reset main, I change the pointer of main, and the current index. This doesn't affect `feature_branch` in any way.
Please clarify your question if I haven't answered it.
@@BriefVid Thanks for answering so quick!
I'll try to explain. Referring to the example that starts roughly at minute 19,
You first created a "feature branch" and it points to commit 3. And then you have done a hard reset for head to point to 2.4. We said that hard reset erases the commit from all three stages. but we still want that cause now the "feature branch is pointing to that commit". Does hard reset behave like soft in this case because there is another branch pointing to that commit (commit 3)?
Please Lmk if I'm still not clear. Thanks again
@@talyawertenteil8300 you are very welcome and I hope I was now able to understand you correctly.
When using "git reset --hard" we don't erase any commit objects.
What we do is move the pointer of HEAD ("soft stage"), and then also modify the staging area ("mixed" stage) and the working dir ("hard" stage). The original commit, where HEAD had pointed to before we issued the the "git reset" command, remains in Git's object database. If it was reachable from another branch - it still is. If it was reachable from another commit - it still is. If it is not reachable, it remains in the internal database of objects until it may be pruned in the future.
I hope I was able to answer the question, please let me know if I missed something :)
@@BriefVid Thank you. I got it now:)
@@talyawertenteil8300 great, thanks for updating :)
I didn't get it. Why are the files that just have been commited are still in the staging area after the commit? The staging area should be clear / empty after the commit. Am I right? 🤔
Hi and thanks for your question.
After the commit, the staging area "equals" the state of HEAD. It is confusing, as "git status" shows the DIFFERENCE between the states to show you what's most important, but if you think about the tree object that the index reprenesents, it would be the same as of HEAD after commiting, as "Commit" basically tells Git - "please use the state of the index and create a new Commit object with that state".
I hope this is clear, please let me know if you have additional questions.
@@BriefVid Totaly clear! Thank!)
@@mo0lo0ko0 Great, thanks for updating :)
When will you get back to networking? Those videos were super-helpful!
Thank you for your encouraging comment @Alfons. I am now focused on git internals for a bit, but I promise to be back to more networking videos soon 🙏🏻
@@BriefVid Awsome! No hurries :)
For the problem at 18:50 I solved it this way:
git branch new_feature
git update-ref refs/heads/main
Is there any drawback doing it this way ?
Now that I think about it, I don't see any difference between "git reset --soft" and "git update-ref" other than the fact that "git reset" lets you use relative commits like HEAD~N
Thanks.
Thank you for your comment. Indeed you are correct, this is a valid way. I wanted to explain `git reset` and its different switches so I demonstrated with this command.
Regarding differences - `git reset --soft` doesn't actually create the commit, meaning you can then change your staging area before committing. If you don't want to change anything, then indeed your approach is practically the same.
I hope this helps!
Just to comment a bit here, so you defined a working tree as any directory that has a git repo in it, then you create a directory using git init and you call it my_repo. Would it maybe be better to call it working_tree?
Thank you for the question.
When I use `git init` I create a repository. The working tree is the currect state of this repo on my filesystem. It is true that in any given time, the contents of this folder ("my_repo") actually represent the working tree, but that is true for any repo - so we usually name the folder as the name of the repo. I hope this makes sense :)
Super video, great contents
Thank you 👍Please share it with others so they can enjoy as well 🙏🏻
Great stuff! Any idea when is part 2 coming out?
Thank you so much!
I don't want to promise, but I will work on it really soon and try to address requests I get from the comments here as well.
Please help me by sharing these videos so more people know about them 🙏🏻
With reset soft, your changes (2.txt) should be in staging. With mixed, your changes (2.txt) should not be in staging but remain in your working tree. With hard, your changes (2.txt) should not exist at all in staging or the working tree.
To undo your previous commit so you can change the commit or message, use 'soft' so that you keep your files and keep them in staging. You could also use 'mixed', but then you have to re-add the files to staging.
All true :) Is there also a question or just a summary for the video?
@@BriefVid Nope! Just a comment for me to reference when I inevitably look up this video again.
Great video as always. First, it will be great if you can cover reflog later in the series, and use reset to get back to a previous state. Perhaps explain a little bit like how to reset a rebase. Secondly, you can think about doing a "tutorial" type of video, where you propose the current and desired state, then provide your solution. That would be a very good exercise to practice the Git skills.
Thank you @Yu Sun! I like your suggestions. I will indeed include `reflog` in the next part then 👍🏻
I also like your "exercise" suggestion, and will try to incorporate it in the next part.
Please help me by sharing these videos so more people know about them!
@@BriefVid Great. Sure no problem.
What happens to the dangling commits
Hi Henry, thanks for your question! They remain in the internal object database, until they are scruned by git's garbage collection mechanism. You can read about it here: git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery