Thank you so much for sharing those amazing Git video tutorials! The quality was truly exceptional, and I found them incredibly helpful in expanding my understanding of Git. Your efforts in creating such valuable content are greatly appreciated. Keep up the fantastic work, and please continue sharing your knowledge with the community.
Thank you so much for your kind words! I really appreciate it, and I'm glad you liked my videos and found them useful. Please share it with more people so they can also benefit from them 🙏🏻
Hi, I have a question. While re-ordering the base for the first commit of a branch in the tutorial - time : 22:15, you didn't checkout to the branch "new_branch" before applying "git rebase --onto". You applied it while you were in the main branch. But in the second case(time: 25:27) you checkout to the branch "feature_2" before proceeding with the "git rebase --onto". Can you help me on this please.
P.S. I understand why we need to checkout to the branch while applying "git rebase" in the second case presented in the tutorial (time: 25:27) --> all thanks to your tutorials. I just couldn't wrap my head around the first scenario.
When you use `onto` and two additional arguments as I did, it doesn't really matter where `HEAD` is pointing to before the command. You are essentially saying - take this changes (introduced in these commits), and apply them on top of this commit. It doesn't matter where yo uare now. I hope this helps :)
Great video, I'm getting a lot of value from it and I think I'm gonna watch all your other videos as well :D Just one question, at 18:47 you rebase paul_branch on main to squash commits 7 and 8. Isn't the chart on the right, wrong? You applied there the changes to 7' and 8' but in fact on the terminal on the left you squashed 7 and 8. Thank you!
Thank you for your kind words and your question! I am not sure I understood your question, but let me try to rephrase the explanation: What I did in the terminal is to squash commit 8 "into" commit 7, thereby creating a new commit - "Commit 7+8", which introduceds both changes of "Commit 7" and "Commit 8", in other words - the state of the tree it references is the same as of the tree after "Commit 7" and then "Commit 8". This is a new commit object, so when we "recreate" Commit 9 - it points to it as its parent, which shows at the chart on the right. at 18:51 you can see on the left the current reachable history (Commit 9' pointing to Commit 7+8...) and its corresponding drawing on the right. When you look at the drawing on the right please follow the "arrows" from HEAD - as it also shows the unreachable original commit 9... Does this clear things up?
@@DevLeonardo Oh wow you are completely right. I wanted to draw it to the side to provide enough space but drew the arrow of the parent of the new commit to "commit 6" instead of "commit 4". My bad and nice catch!!
@@BriefVid Ok, it makes sense now, thank you! :D By the way, I'm also creating videos about programming (and some about git!) so I kind of understand how much effort is needed to come up with a 30 minutes video, again congratulations for the quality content!
Thank you for this great video, I'm learning so much from it! I have one question - why at 29:44 Commit 17+19 is pointing to Commit 14 and not Commit 15?
I could probably get by my entire life without rebasing, but thanks for the video! I find very strange that the rebase argument have a completely different meaning depending on the options, like --onto. Options should ideally only some minor aspect of how a command is carried out, not completely change the meaning of the arguments. It confuses me...
you say i should find comits to apply at the top of the active Branch when rebasing, but for example if history derives and merged again: for example commit1 then derives in to branches commit2 and commit3 for example ,and then commit2 also derives into commit4 and commit5 and then merged into merge commit 6, and what if i want to rebase branch that had derived history(that starts from commit2) to the top of the branch starts at commit 3? Diff(x,parent(x)) if x have two parents
The short answer is - mixing rebase and merge is really difficult and error-prone. I would strongly advise against it :) You can rebase on your local linear history, but once you merge - many things could go wrong. For this specific question, git would, by default, take the first parent of the commit. I hope this helps :)
All this example using rebase are valid when we don't have conflits, we just want rewrite the history, right? To deal with conflits merge still the better aproach, or am i wrong?
Thanks for the question :) Do you mean local conflicts during rebase (that can happen) or conflicts with the remote? The 5th video in this series discusses the difference between rebase and merge. Bottom line - conflicts resolution is the same in both, but you should never rebase things that were pushed and someone else might have relied on. The other vido explains this much better than this short paragraph, but feel free to ask here or as a comment to that video if anything is unclear :)
QUESTION : Any commit is full snapshot of stagging Area or just changes what they rememberd? I tried myself and found commit is not a full snapshot but only changes which they know. create master branch file_1 created ( 1st commit) . Now checkout "feat" branch. Do a 2nd commit file_2 created. Do a 3rd commit file_3 created. Do a 4th commit file_4 created. Do a 5th commit file_5 created. Do a 6th commit file_6 created. Do a 7th commit file_7 created. Now "git switch master". git cherry-pick "7th commit hash" And boom.. In master you see only file_1 and after file_7 created. Not a full snapshot. ( I mean even 7th is latest commit in feat but it doesn't have full snapshot, just their changes what they remember at that time). That's why file_2 to file_6 are not comes in the master. Because we use cherry pick and not merge.
Thank you for your question, I am afraid you are confusing "commit object" with "cherry-pick". A commit object is the entire snapshot (more accurately, a pointer to a tree object that describes the entire snapshot). git cherry-pick actually computes the difference between the specified commit and its parent, and then applies them to the active commit. So it computes the diff between Commit 7 and Commit 6, and applies it on top of `master`, in your example. I hope this is clear
@@BriefVid 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.. Wow man you are such a genius.
already found, not sure though, but seems true :) F - full t-shirt area W - constant white area (letters + circle) w - white segment area C - full internals of circle area (W + w) / F == w / C (W + w) * C == w * F W * C == w * (F - C) w = W * C / (F - C)
Thank you so much for sharing those amazing Git video tutorials! The quality was truly exceptional, and I found them incredibly helpful in expanding my understanding of Git. Your efforts in creating such valuable content are greatly appreciated. Keep up the fantastic work, and please continue sharing your knowledge with the community.
Thank you so much for your kind words! I really appreciate it, and I'm glad you liked my videos and found them useful. Please share it with more people so they can also benefit from them 🙏🏻
Thanks!
Thank *you* for supporting me, I'm glad you found it useful! 🙏🏻🙏🏻
29:39 a mistake here... the parent of commit 17+19 is commit 15' instead of 14'
You are absolutely right - it is supposed to be Commit 15, I got the arrow pointing to the wrong commit, my bad
Thanks for the series
Thank you very much
Hi, I have a question. While re-ordering the base for the first commit of a branch in the tutorial - time : 22:15, you didn't checkout to the branch "new_branch" before applying "git rebase --onto". You applied it while you were in the main branch. But in the second case(time: 25:27) you checkout to the branch "feature_2" before proceeding with the "git rebase --onto". Can you help me on this please.
P.S. I understand why we need to checkout to the branch while applying "git rebase" in the second case presented in the tutorial (time: 25:27) --> all thanks to your tutorials. I just couldn't wrap my head around the first scenario.
When you use `onto` and two additional arguments as I did, it doesn't really matter where `HEAD` is pointing to before the command. You are essentially saying - take this changes (introduced in these commits), and apply them on top of this commit. It doesn't matter where yo uare now.
I hope this helps :)
@@BriefVid Thank you. I get it now.
Great video, I'm getting a lot of value from it and I think I'm gonna watch all your other videos as well :D
Just one question, at 18:47 you rebase paul_branch on main to squash commits 7 and 8. Isn't the chart on the right, wrong?
You applied there the changes to 7' and 8' but in fact on the terminal on the left you squashed 7 and 8.
Thank you!
Thank you for your kind words and your question!
I am not sure I understood your question, but let me try to rephrase the explanation:
What I did in the terminal is to squash commit 8 "into" commit 7, thereby creating a new commit - "Commit 7+8", which introduceds both changes of "Commit 7" and "Commit 8", in other words - the state of the tree it references is the same as of the tree after "Commit 7" and then "Commit 8". This is a new commit object, so when we "recreate" Commit 9 - it points to it as its parent, which shows at the chart on the right. at 18:51 you can see on the left the current reachable history (Commit 9' pointing to Commit 7+8...) and its corresponding drawing on the right.
When you look at the drawing on the right please follow the "arrows" from HEAD - as it also shows the unreachable original commit 9...
Does this clear things up?
@@BriefVid At 18:51 in the terminal I see two branches having as parent Commit 4.
john who has commits (1,2,3,4)
@@DevLeonardo Oh wow you are completely right. I wanted to draw it to the side to provide enough space but drew the arrow of the parent of the new commit to "commit 6" instead of "commit 4". My bad and nice catch!!
@@BriefVid Ok, it makes sense now, thank you! :D
By the way, I'm also creating videos about programming (and some about git!) so I kind of understand how much effort is needed to come up with a 30 minutes video, again congratulations for the quality content!
@@DevLeonardo Thanks a lot, I hope I can keep providing it constantly 🙏🏻🙏🏻
Thank you for this great video, I'm learning so much from it! I have one question - why at 29:44 Commit 17+19 is pointing to Commit 14 and not Commit 15?
Thank you @ania, you are perfectly correct - it is supposed to be Commit 15, I got the arrow pointing to the wrong commit, my bad 😇
I could probably get by my entire life without rebasing, but thanks for the video! I find very strange that the rebase argument have a completely different meaning depending on the options, like --onto. Options should ideally only some minor aspect of how a command is carried out, not completely change the meaning of the arguments. It confuses me...
You are welcome :)
I agree it's confusing, I am not here to defend Git's UX - but I think rebase is a super powerful tool we should embrace
you say i should find comits to apply at the top of the active Branch when rebasing, but for example if history derives and merged again: for example commit1 then derives in to branches commit2 and commit3 for example ,and then commit2 also derives into commit4 and commit5 and then merged into merge commit 6, and what if i want to rebase branch that had derived history(that starts from commit2) to the top of the branch starts at commit 3? Diff(x,parent(x)) if x have two parents
The short answer is - mixing rebase and merge is really difficult and error-prone. I would strongly advise against it :) You can rebase on your local linear history, but once you merge - many things could go wrong.
For this specific question, git would, by default, take the first parent of the commit.
I hope this helps :)
All this example using rebase are valid when we don't have conflits, we just want rewrite the history, right? To deal with conflits merge still the better aproach, or am i wrong?
Thanks for the question :)
Do you mean local conflicts during rebase (that can happen) or conflicts with the remote?
The 5th video in this series discusses the difference between rebase and merge. Bottom line - conflicts resolution is the same in both, but you should never rebase things that were pushed and someone else might have relied on.
The other vido explains this much better than this short paragraph, but feel free to ask here or as a comment to that video if anything is unclear :)
QUESTION :
Any commit is full snapshot of stagging Area or just changes what they rememberd?
I tried myself and found commit is not a full snapshot but only changes which they know.
create master branch file_1 created ( 1st commit) .
Now checkout "feat" branch.
Do a 2nd commit file_2 created.
Do a 3rd commit file_3 created.
Do a 4th commit file_4 created.
Do a 5th commit file_5 created.
Do a 6th commit file_6 created.
Do a 7th commit file_7 created.
Now "git switch master".
git cherry-pick "7th commit hash"
And boom..
In master you see only file_1 and after file_7 created.
Not a full snapshot. ( I mean even 7th is latest commit in feat but it doesn't have full snapshot, just their changes what they remember at that time).
That's why file_2 to file_6 are not comes in the master.
Because we use cherry pick and not merge.
Thank you for your question,
I am afraid you are confusing "commit object" with "cherry-pick".
A commit object is the entire snapshot (more accurately, a pointer to a tree object that describes the entire snapshot).
git cherry-pick actually computes the difference between the specified commit and its parent, and then applies them to the active commit. So it computes the diff between Commit 7 and Commit 6, and applies it on top of `master`, in your example.
I hope this is clear
@@BriefVid 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..
Wow man you are such a genius.
Well done@@DhavalAhir10 , I am glad you learned from it 👏🏻👏🏻
Like first, then watch. 🎉
thank you! btw can you please write the equation of area the white color used on your t-shirt?)
already found, not sure though, but seems true :)
F - full t-shirt area
W - constant white area (letters + circle)
w - white segment area
C - full internals of circle area
(W + w) / F == w / C
(W + w) * C == w * F
W * C == w * (F - C)
w = W * C / (F - C)
@@qwer6323this is the original:
xkcd.com/688/