"Please try to avoid doing a force push to your _main_ branch" Totally agree! However, I would like to add that in (feature) branches where you're the only one working on force pushing can be very helpful to keep a clean history. For example, if one of the commits broke the build (or unit tests or whatever) then I'd just remove/fix that commit with a force push. It also helps to always have a working build if you ever use git-bisect :) Love these vids!
It should probably be mentioned that force-pushing is very useful and completely normal when working on your own feature-branches (that others don't push to). Rewriting history is fine when rebasing your feature-branch on the main-branch before submitting a PR for instance. I know we're only talking a single branch here for simplicity, but I think it's important to mention that force-push isn't just a last-ditch-effort tool.
Hey Scott, more great stuff, again, thanks! And let me say that I enjoy the no edit style you've adopted. It makes what's happening easier to follow and add a certain humanistic feeling to your tutorials that just isn't found in other, highly edited videos. Keep up the great work!
Scott kudos for this series! They are valuable and help developers to be more effective. These concepts and their implementation should be prerequisite in any coding focused training course.
These are great videos. I know Git has been around for a while - but it's very complex and uses its own terminology and thus I think these are timeless.
Scott, really enjoying this series - looking forward to what is next. I'm not sure if it is in your road map for this or not - but I would love to see a video on best practices around common git workflows. I work on an ops team and we are getting into git for our PowerShell work. Again, thanks for the content.
Make it intermittently rain with those dozens of TH-cam dollars! But in all honestly I have learnt so much .Net from your blogs and now from your videos
Your videos have been a great help! A request -- Please make a video on how to generate SSH keypair, authenticate public key, and adding SSH keypair to ssh-agent using Powershell. Also, if possible, a video covering 'git push --force-with-lease' with its different parameters/options would be a big help as well.
Can you talk about some basic networking stuff like localhost and ports? I’ve never really understood it but trying to use WSL2 and learn a bit of web dev so it’s been coming up more often.
As a concrete example of "what" changes during a history rewrite, pause at time-index 12:56 and note that from the third commit message in the log (left side of the screen) downwards, the commit SHA1 matches the corresponding commit's SHA1 on GitHub (right side of the screen). However, the top two "rebased/rewritten" commits in the log now have different SHA1 values because the parent commit of "Update test - Copy.txt (23c5163)" changed to the commit "Merge pull request #6 (d4fa5c9)" from the previous parent commit of "Merge pull request#5 (3a3664a)" i.e., the commit that was removed. Since a commit's SHA1 value incorporates the commit's parent SHA1 value, changing the parent of a commit makes that commit and subsequent commits in the timeline appear as all-new commits.
To add to this, the SHA1 depends on the entire history (comments, authors, parents, content) of a commit. So even changing one letter in one file during a rebase will change the SHA1 of all subsequent commits. That's why force breaks things for people who are still referencing the old commit.
One of my favorite things I learned from my job was how to update a hard drive's firmware or an SSD's firmware through the command 'hdparm'. The following below is the exact syntax to use to tell hdparm to try to update the drive's firmware: hdparm /dev/sda --yes-i-know-what-i-am-doing --please-destroy-my-drive --fwdownload mybinary.bin It literally makes you type out in verbose language: --yes-i-know-what-i-am-doing --please-destroy-my-drive I thought my boss was joking with me and a coworker when he gave us that command. No way could those seriously be the arguments to use! He's warning us to be careful! Those are the real arguments.
Hi Scott, first of all, amazing your explanation makes it easy to understand anything, thanks so much for that. I have a doubt, usually, when you do a rebase-interactive (-i) you got a prompt with some text information about the commits, etc... I saw you got that prompt in the VS Code, my Windows Terminal prompt me to "VI editor" :( How can I configure my Windows Terminal to prompt me to the VS Code ?? Thanks in advance. Cheers!
Great video, Scott. If I cloned your repo before git push -force, what should I do to update my local repo? git pull? Also, is there a way to fix the "4 commits behind, 1 commit ahead" issue in github or is it just a warning message? Please explain more not recommended git practices (and how to deal with them) in future videos. Thanks!
hypothetically, what would happen subsequently after a dev re-wrote history by doing a git push force? How could an individual fix this, back to the point where every one can all have the same history again?.. you should do a segment on that
If I had cloned your repo before you removed the password (ie when ede923b was the newest commit), would I need to do something special to get back in sync, or should I just be able to pull again?
If you run a git fetch you'll see that you'd be "desynced" like he showed. To get back to the "real" main branch, you'd have to reset it. I usually use: git reset --hard / So for instance, on branch named master with remote named origin: git reset --hard origin/master Beware that this will orphan your local commits not on the remote like he explained. It's like a force pull if that makes sense.
Thanks a lot sir, no wonder ppl really really really hate something with "-force", so in this example, the only way to get around with a posted password is to make in invalid on the backend. I think similar situation applies to mistakenly added unwanted files to .gitignore ? So no way to undo it once it is pushed !?
As long as you are the only person referencing that branch, you're fine. Once it is 'published' (to github for example), it's a Very Bad Idea. Unless you know for sure that no-one else is referencing it. Or you don't care.
Can you do a video on how to backup your entire repository ? I saw option on bundles and achieve commands but is that the best way or just zip up the directory .
He is using the new Windows Terminal with Powershell, no WSL required :) Windows Terminal can be found in the Microsoft app store. It's HIGHLY customisable. He also mentioned in this video that he is using Pretty Prompt to display additional information about the directory location.
Showing force at all without mentioning - - force-with-lease is problematic. A good follow-up could be to show how to do it right, which is in your own branch, with lease, to get a clean commit history. In this case it's not only fine to force (with lease) push, it's what makes rebase really useful (and harmless).
@@shanselman Sorry I missed it. Glad you mentioned it. I'd love to send you a PR, but isn't the scenario here that the person doing the rewrite would be the one making the PR? I mean, as you said in the video, the secret scenario is a little contrived, as that secret is compromised now and the right mitigation is to change the secret. I think the justified scenario for --force-with-lease is the following (at least it's the one I'm doing on almost every PR I do, I know you know how to do all that, just spelling it out for accuracy): publish a PR, get some code review, make some changes, some of which make the commit history as it is hard to follow because some things are done, undone, and re-done differently. To give future readers a clear view of what the change really is about, a cleaned up commit history is useful. So you do an interactive rebase (the most common way I do it is to have a new correction commit that I fixup into the existing one, when it's a single commit PR, or a more complex interactive rebase in more advanced scenarios), then push force with lease because there's no other way to get the fixes in without doing a new PR. As an aside, VS online is currently a little better than GitHub at showing PR history & diffs in such scenarios, hope GH catches up on that. I think that would be a nice follow-up that would also be an opportunity to talk about other cool git practices around good PRs and code reviews.
If you add your AWS keys on accident you’ll know when you get the insane bill from people spinning up Bitcoin mining machines in your aws account, haha. This actually happened to multiple people while I was in university
But if you put in another PR with the password removed, wouldn't the password still be viewable in the git history? You would have to do a git push --force to prevent this wouldn't you? Also, I cloned another repo because it had the folder structure I wanted them completely developed a new project in it. Now the git history for this project shows the full history from the previous project, even though there are no longer any files in my project related to the original repo. How can I remove (squash?) all the history prior to a specific point?
If you only want to adopt the cloned repos folder structure first clone the repo, the create a new folder for your project and copy the folder structure to the new folder and git init a new repo there. I don't think it is a good idea to reuse an existing repo as the starting point for a new project.
@@grumpydeveloper69 Thanks Thomas and Johan. I already have this setup in a private repo, and wouldn't mind keeping all my commits for the last two months. If I use an interactive rebase now and drop any old commits, will the code in those commits still exist?
@@st3ddyman You could do it. See this stackoverflow that explain different option including the rebase option as shown in @Scott Hanselman video. stackoverflow.com/questions/37471740/how-to-copy-commits-from-one-git-repo-to-another
"Please try to avoid doing a force push to your _main_ branch"
Totally agree! However, I would like to add that in (feature) branches where you're the only one working on force pushing can be very helpful to keep a clean history. For example, if one of the commits broke the build (or unit tests or whatever) then I'd just remove/fix that commit with a force push. It also helps to always have a working build if you ever use git-bisect :)
Love these vids!
Gracias Scott!!! It's an honor :)
It should probably be mentioned that force-pushing is very useful and completely normal when working on your own feature-branches (that others don't push to). Rewriting history is fine when rebasing your feature-branch on the main-branch before submitting a PR for instance. I know we're only talking a single branch here for simplicity, but I think it's important to mention that force-push isn't just a last-ditch-effort tool.
Great point!
With lease. --force-with-lease, always, never --force.
@@BertrandLeRoy Yep, he should do a follow up video explaining WHEN to use force and how to do it properly
Hey Scott, more great stuff, again, thanks! And let me say that I enjoy the no edit style you've adopted. It makes what's happening easier to follow and add a certain humanistic feeling to your tutorials that just isn't found in other, highly edited videos. Keep up the great work!
@5:00 S.H.’s voice saying “Thank you, friend. We want you to be quiet now.” Is the creepiest thing I have ever heard outside of a horror movie.
👁
You usually only hear that line if you're about to swim with the fish.
Scott kudos for this series! They are valuable and help developers to be more effective. These concepts and their implementation should be prerequisite in any coding focused training course.
I must say this is amazing and please do continue to do this way of teaching. I wonder who all were lucky to work with someone like you :)
"... or a really bad sequel" - hilarious as ever Mr H.
Love your vids man. The console and wsl series helped convince me to come back to windows after 8 years on OS X.
I have been working with git for a while but there's always something to learn and sure enough, your videos gave me more understanding. Thanks!
As requested - liked that, subscribed and shared with friends :) Keep up with a great work!
Very grateful for all the stuff you teach us Scott! Wonderful series. I'm always looking forward to a new episode. Thanks a lot!
I love your channel, Mr. Hanselman. The depth of your knowledge and your calm delivery are worth coming back for. Content for clear minds 😌
These are great videos. I know Git has been around for a while - but it's very complex and uses its own terminology and thus I think these are timeless.
Scott, really enjoying this series - looking forward to what is next. I'm not sure if it is in your road map for this or not - but I would love to see a video on best practices around common git workflows. I work on an ops team and we are getting into git for our PowerShell work. Again, thanks for the content.
Wonderful session, Scott, Thank you very much.
Make it intermittently rain with those dozens of TH-cam dollars! But in all honestly I have learnt so much .Net from your blogs and now from your videos
I like Scott. Very good learning resource. I've referred this vid to our junior devs (and some of our senior ones LOL).
Your videos have been a great help!
A request -- Please make a video on how to generate SSH keypair, authenticate public key, and adding SSH keypair to ssh-agent using Powershell.
Also, if possible, a video covering 'git push --force-with-lease' with its different parameters/options would be a big help as well.
Can you talk about some basic networking stuff like localhost and ports? I’ve never really understood it but trying to use WSL2 and learn a bit of web dev so it’s been coming up more often.
Great to know you're becoming rich with this great series of videos !!!
I burst out laughing when you were trying to paste that thing, I just think you're very funny. (been following you since 2015)
Love the ambience of your room. Feels so divine. 👍
As a concrete example of "what" changes during a history rewrite, pause at time-index 12:56 and note that from the third commit message in the log (left side of the screen) downwards, the commit SHA1 matches the corresponding commit's SHA1 on GitHub (right side of the screen). However, the top two "rebased/rewritten" commits in the log now have different SHA1 values because the parent commit of "Update test - Copy.txt (23c5163)" changed to the commit "Merge pull request #6 (d4fa5c9)" from the previous parent commit of "Merge pull request#5 (3a3664a)" i.e., the commit that was removed. Since a commit's SHA1 value incorporates the commit's parent SHA1 value, changing the parent of a commit makes that commit and subsequent commits in the timeline appear as all-new commits.
To add to this, the SHA1 depends on the entire history (comments, authors, parents, content) of a commit. So even changing one letter in one file during a rebase will change the SHA1 of all subsequent commits. That's why force breaks things for people who are still referencing the old commit.
Dev: git push --force
Computer: are you sure you know what you are doing? If yes, type: I'm about to screw things up and press enter
One of my favorite things I learned from my job was how to update a hard drive's firmware or an SSD's firmware through the command 'hdparm'. The following below is the exact syntax to use to tell hdparm to try to update the drive's firmware:
hdparm /dev/sda --yes-i-know-what-i-am-doing --please-destroy-my-drive --fwdownload mybinary.bin
It literally makes you type out in verbose language: --yes-i-know-what-i-am-doing --please-destroy-my-drive
I thought my boss was joking with me and a coworker when he gave us that command. No way could those seriously be the arguments to use! He's warning us to be careful!
Those are the real arguments.
Great video again. I had a good laugh when Alexa interrupted
Hi Scott, first of all, amazing your explanation makes it easy to understand anything, thanks so much for that.
I have a doubt, usually, when you do a rebase-interactive (-i) you got a prompt with some text information about the commits, etc... I saw you got that prompt in the VS Code, my Windows Terminal prompt me to "VI editor" :( How can I configure my Windows Terminal to prompt me to the VS Code ??
Thanks in advance.
Cheers!
That's the core.editor config item! stackoverflow.com/questions/2596805/how-do-i-make-git-use-the-editor-of-my-choice-for-commits
Greyishbeard hanselman approaching final form.
Don’t think we didn’t catch the caveat at the end where you said “avoid doing this to MAIN” (paraphrase).
Great video, Scott. If I cloned your repo before git push -force, what should I do to update my local repo? git pull? Also, is there a way to fix the "4 commits behind, 1 commit ahead" issue in github or is it just a warning message? Please explain more not recommended git practices (and how to deal with them) in future videos. Thanks!
Just tell him change his password
hypothetically, what would happen subsequently after a dev re-wrote history by doing a git push force? How could an individual fix this, back to the point where every one can all have the same history again?.. you should do a segment on that
If I had cloned your repo before you removed the password (ie when ede923b was the newest commit), would I need to do something special to get back in sync, or should I just be able to pull again?
If you run a git fetch you'll see that you'd be "desynced" like he showed. To get back to the "real" main branch, you'd have to reset it.
I usually use: git reset --hard /
So for instance, on branch named master with remote named origin:
git reset --hard origin/master
Beware that this will orphan your local commits not on the remote like he explained. It's like a force pull if that makes sense.
This is nice to have vlog
Thanks a lot sir, no wonder ppl really really really hate something with "-force", so in this example, the only way to get around with a posted password is to make in invalid on the backend.
I think similar situation applies to mistakenly added unwanted files to .gitignore ? So no way to undo it once it is pushed !?
If this happens in the feature branch before making a pull request still is a bad idea?
As long as you are the only person referencing that branch, you're fine. Once it is 'published' (to github for example), it's a Very Bad Idea. Unless you know for sure that no-one else is referencing it. Or you don't care.
Flash point
Can you do a video on how to backup your entire repository ? I saw option on bundles and achieve commands but is that the best way or just zip up the directory .
"...and kill us all" 😄. Made my day
What color theme, extensions etc do you use with VS, VS Code ?
That theme is called Yonce
Thank you so much, now i know better!
Would you do this if someone deleted everything in the repo? 🤔
Is your themed powershell as a result of WSL? is it possible without using WSL? I tried setting it up unsuccessfully with WSL.
He is using the new Windows Terminal with Powershell, no WSL required :) Windows Terminal can be found in the Microsoft app store. It's HIGHLY customisable. He also mentioned in this video that he is using Pretty Prompt to display additional information about the directory location.
google "hanselman pretty prompt"
Scott . Can You please put playlist link on Description please!
Good idea
Showing force at all without mentioning - - force-with-lease is problematic. A good follow-up could be to show how to do it right, which is in your own branch, with lease, to get a clean commit history. In this case it's not only fine to force (with lease) push, it's what makes rebase really useful (and harmless).
I did mention force-with-lease.
Do you want to send another PR and let's do another, ok?
@@shanselman Sorry I missed it. Glad you mentioned it. I'd love to send you a PR, but isn't the scenario here that the person doing the rewrite would be the one making the PR? I mean, as you said in the video, the secret scenario is a little contrived, as that secret is compromised now and the right mitigation is to change the secret. I think the justified scenario for --force-with-lease is the following (at least it's the one I'm doing on almost every PR I do, I know you know how to do all that, just spelling it out for accuracy): publish a PR, get some code review, make some changes, some of which make the commit history as it is hard to follow because some things are done, undone, and re-done differently. To give future readers a clear view of what the change really is about, a cleaned up commit history is useful. So you do an interactive rebase (the most common way I do it is to have a new correction commit that I fixup into the existing one, when it's a single commit PR, or a more complex interactive rebase in more advanced scenarios), then push force with lease because there's no other way to get the fixes in without doing a new PR. As an aside, VS online is currently a little better than GitHub at showing PR history & diffs in such scenarios, hope GH catches up on that.
I think that would be a nice follow-up that would also be an opportunity to talk about other cool git practices around good PRs and code reviews.
If you add your AWS keys on accident you’ll know when you get the insane bill from people spinning up Bitcoin mining machines in your aws account, haha. This actually happened to multiple people while I was in university
But if you put in another PR with the password removed, wouldn't the password still be viewable in the git history? You would have to do a git push --force to prevent this wouldn't you?
Also, I cloned another repo because it had the folder structure I wanted them completely developed a new project in it. Now the git history for this project shows the full history from the previous project, even though there are no longer any files in my project related to the original repo. How can I remove (squash?) all the history prior to a specific point?
Use interactive rebase to drop the old commits or start a new branch and cherry-pick the new ones over.
If you only want to adopt the cloned repos folder structure first clone the repo, the create a new folder for your project and copy the folder structure to the new folder and git init a new repo there. I don't think it is a good idea to reuse an existing repo as the starting point for a new project.
@@grumpydeveloper69 Thanks Thomas and Johan. I already have this setup in a private repo, and wouldn't mind keeping all my commits for the last two months.
If I use an interactive rebase now and drop any old commits, will the code in those commits still exist?
@@st3ddyman You could do it. See this stackoverflow that explain different option including the rebase option as shown in @Scott Hanselman video. stackoverflow.com/questions/37471740/how-to-copy-commits-from-one-git-repo-to-another
Great video!!! :))
MAKE ROOM TOUR VIDEO
🥰 i got ❤️
I think you should also include learning Vim in this series. It's going to be really helpful for many of us.
Well, assuming that you know how to vim considering the massive years of experience you've got. But, hey, great videos, Scott! Love'em!
In school (1990 - 1995) Git was not invented :)
That explains why it wasn't taught! ;)
Who is here after Spiderman no way home meme?
Start Videos on ML...