was searching for cherry pick and mate just gonna say you explained it in the most simplest and understandable way. those animation with actual commit Strings was so much helpful while seeing the commands get executed. Loved your content!!
Brilliant !!. simplicity combine with your animation and your delivery = treasure of a story teller about git. anyone wants to learn git, better sit down/listen to this gentleman and soak it up. my friend, you are one in a million for sharing your knowhow and for that I am so Thankful !!.
Git cherry pick tutorial: th-cam.com/video/i657Bg_HAWI/w-d-xo.html. I also have more Git videos! th-cam.com/play/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM.html Lastly, a written reference of what was explained in this video is available at: www.themoderncoder.com/git/
First of all, great video! Extremely helpful and I learned a lot. Secondly, I would argue that starting at 4:35, if you are encountering this problem, then you have a personal problem managing your own work. Try not to get into a situation where you yourself have manually edited the same file differently in two branches. Just my opinion 🤷
Yeah that’s fair, the example is a little contrived. It’s funny you point this out because I put off doing the screen recording for that part because I was struggling to think of a realistic, yet somewhat straightforward situation that would cause a merge conflict. But those two qualities don’t really go together when you’re talking about merge conflicts
Explained in a very comprehensive way, well done, thanks. Do you mind sharing which tools and technics you used for recording this material? Would be interesting to see it as a separate video.
Thanks for the comment, glad these are helping you. I plan to release a comprehensive series of Git videos in the coming months, and after that will do a video on how I made these.
Trying to get better with reading conflict diffs... when you did the manual resolution you excluded the instagram_username, how did you know to omit i? Does it matter which branch is newest?
In this case, all I was thinking about was manually editing that block to be whatever I wanted it to look like after the merge. It shouldn't matter which is newer because you're moving commits between branches. Since the branches are tracking two different "flows" of work, the timing of when those commits made it into the Git tree isn't relevant to what the merge should look like. If you're on a team, you'd need to collaborate with the author of the code block in question and work it out.
I honestly think this was a miss on his part (especially by the fact that it was never explained in the video starting at 2:57). The nav branch included the instagram_username line but the main did not. When fixing the merge conflict, he should have known to keep that line in the final product because the nav branch developer added it.
I’d probably agree that keeping lines that were newly added (like instagram_username) won’t generally be a problem, but it’s not failsafe in all situations. The safer advice would be to confer with both branch authors, or make a case-by-case judgement call if you’re the subject matter expert. So I still stand behind the advice from earlier in the thread, but now that I’m talking through all this, I agree it was a miss not to include this nuance in the video. I should probably make a dedicated video on merge conflict resolution strategy.
If nav is merged using a "git merge" both commits remain (the original and the cherry-picked commit). If nav is rebased onto main, then the cherry-picked commit WON'T be replayed onto main and Git will output something like this: "warning: skipped previously applied commit"
If you use VS Code you can either open config.yml manually via the file explorer or (if you've configured VS Code to be able to launch from the command line code.visualstudio.com/docs/setup/mac#_launching-from-the-command-line) you could type "code config.yml"
Sorry about that confusion. I wanted to demonstrate what aborting the cherry pick would look like. Just imagine at 2:11 I never issued the abort in the first place.
Specifying the hash d81b1f0 in the commit subject is irrelevant because this commit could never reach the remote repository. If you do a git rebase of your nav branch or never push your nav branch!
You’re saying the cherry picked commit on main could never reach the remote repository? I guess what I was trying to demonstrate was that the nav branch was already in the remote repository because another collaborator authored it.
These videos are a treasure and should be protected for future generations.
was searching for cherry pick and mate just gonna say you explained it in the most simplest and understandable way.
those animation with actual commit Strings was so much helpful while seeing the commands get executed.
Loved your content!!
Heck yeah, glad it helped
Your Videos are just the BEST Explanation about Git... with the Animation... it helps a lot
Brilliant !!. simplicity combine with your animation and your delivery = treasure of a story teller about git. anyone wants to learn git, better sit down/listen to this gentleman and soak it up.
my friend, you are one in a million for sharing your knowhow and for that I am so Thankful !!.
You're on the way to the top with this style of explanation. Well done and thanks for making these.
looking forward to git-stash :)
Here you go - just posted today: th-cam.com/video/BSLzA8oCT7g/w-d-xo.html
Git cherry pick tutorial: th-cam.com/video/i657Bg_HAWI/w-d-xo.html. I also have more Git videos! th-cam.com/play/PLfU9XN7w4tFwKwh_xPSQ_X1-hROQEpHnM.html Lastly, a written reference of what was explained in this video is available at: www.themoderncoder.com/git/
Thank you for such an easy explanation! The visuals are amazing as well!
Great Explanation!!!
All things are easy to understand because of Graphical demonstration.
Glad it was helpful!
you are amazing bro, visual representation helped alot.
damn those animations really making it easier to understand gj
Thanks for these valuable videos 🔥🔥🔥
Thank you! Very clear and easy-to-use explanation!
First of all, great video! Extremely helpful and I learned a lot. Secondly, I would argue that starting at 4:35, if you are encountering this problem, then you have a personal problem managing your own work. Try not to get into a situation where you yourself have manually edited the same file differently in two branches. Just my opinion 🤷
Yeah that’s fair, the example is a little contrived. It’s funny you point this out because I put off doing the screen recording for that part because I was struggling to think of a realistic, yet somewhat straightforward situation that would cause a merge conflict. But those two qualities don’t really go together when you’re talking about merge conflicts
Well and clear explanation, thanks.
Yo man, these are some seriously good underrated vids!❤
Appreciate it. If you ever come across someone who could benefit from a video of mine, please share it!
Man you are the BEST!
Very clear explanation. Thank you, it was very helpful.
Thanks a lot, this video was exactly what I needed
Great Graphical demonstration. Thanks!
Your videos were helpful. Thanks mate!
Thank you so much. The best git videos I've ever seen.
Appreciate that compliment, wow!
Really informative video!
But I have 1 question left: at 1:22 what would the "--skip" command do?
If you’re cherry picking multiple commits, -skip will tell Git to skip the current commit in the sequence and move onto the next one
@@themoderncoder so will it work as the abort-option for this particular commit or just postpone the conflict to the end of the sequence?
@@zigzagging256 yes exactly. It essentially works as an abort but only for that specific commit in the sequence.
@@themoderncoder understood. Thank you very much!
Thank you so much, Great Explation.
I love your content!
Thank you!
Explained in a very comprehensive way, well done, thanks. Do you mind sharing which tools and technics you used for recording this material? Would be interesting to see it as a separate video.
Thanks for the comment, glad these are helping you. I plan to release a comprehensive series of Git videos in the coming months, and after that will do a video on how I made these.
Thank you so much for these fantastic videos.
Thanks for watching them :)
saved my life
Good job bro!
Treasure found!
Trying to get better with reading conflict diffs... when you did the manual resolution you excluded the instagram_username, how did you know to omit i? Does it matter which branch is newest?
In this case, all I was thinking about was manually editing that block to be whatever I wanted it to look like after the merge. It shouldn't matter which is newer because you're moving commits between branches. Since the branches are tracking two different "flows" of work, the timing of when those commits made it into the Git tree isn't relevant to what the merge should look like. If you're on a team, you'd need to collaborate with the author of the code block in question and work it out.
I honestly think this was a miss on his part (especially by the fact that it was never explained in the video starting at 2:57). The nav branch included the instagram_username line but the main did not. When fixing the merge conflict, he should have known to keep that line in the final product because the nav branch developer added it.
I’d probably agree that keeping lines that were newly added (like instagram_username) won’t generally be a problem, but it’s not failsafe in all situations. The safer advice would be to confer with both branch authors, or make a case-by-case judgement call if you’re the subject matter expert. So I still stand behind the advice from earlier in the thread, but now that I’m talking through all this, I agree it was a miss not to include this nuance in the video. I should probably make a dedicated video on merge conflict resolution strategy.
You are the best
wow man!
This is good stuff.
thanks, it worked for me
Impressive. Subscribed.
I saw you commented on both my cherry pick videos! Thanks for taking the time to say that - I really appreciate the support
What happen when nav is merged into main after a cherry pick. Will the old hashes for cherry pick commits be merged still?
If nav is merged using a "git merge" both commits remain (the original and the cherry-picked commit). If nav is rebased onto main, then the cherry-picked commit WON'T be replayed onto main and Git will output something like this: "warning: skipped previously applied commit"
@@themoderncoder Thanks
if we are using vi config.yml for vim ide , what command we will use for vs code ide?
If you use VS Code you can either open config.yml manually via the file explorer or (if you've configured VS Code to be able to launch from the command line code.visualstudio.com/docs/setup/mac#_launching-from-the-command-line) you could type "code config.yml"
😮ok but what terminal is he using, its beautiful
I gotchu
th-cam.com/video/DetYI7bjNrw/w-d-xo.html
@2:11 you rolled back but did not issue the cherry-pick command
Sorry about that confusion. I wanted to demonstrate what aborting the cherry pick would look like. Just imagine at 2:11 I never issued the abort in the first place.
Specifying the hash d81b1f0 in the commit subject is irrelevant because this commit could never reach the remote repository.
If you do a git rebase of your nav branch or never push your nav branch!
You’re saying the cherry picked commit on main could never reach the remote repository? I guess what I was trying to demonstrate was that the nav branch was already in the remote repository because another collaborator authored it.
I just drop the stash.