4 ms·

Depends. Sometimes it's easier to tear down everything and start from scratch.

by sdevonoes 4y ago

leoff 4y ago
Isn't this what a `git reset --hard` does?
- sethammons 4y ago
  I've gotten out of sync with the remote where that would still fail and decided to just reclone. I think the reason it happened is git-history purists rewriting and pushing.
- solardev 4y ago
  That just resets to your last local commit. To sync back up to the remote, you need at least do a git reset origin/HEAD --hard (and capitalization matters, I don't know why). But that doesn't work if you rewrote history in some way (I'm not sure why that's even possible). In that case your local git can get pretty messed up, some gui tools (IntelliJ) start to bug out and fail to diff properly, and it's easier to just start over. After ten years of using git, I've more confused by it than ever. People here keep talking about mental models, but I've read a shit ton of docs on it and am still totally confused. Probably some of us just aren't smart enough lol.
  - 5e92cb50239222b 4y ago
    Not sure what origin/HEAD is supposed to point to. HEAD is a ref that points to the tip of the current branch. It's not going to be available for remotes (it just doesn't make sense). To reset the current branch, you need to do two things: $ git fetch to fetch commits from the default remote and point remote branches accordingly, and $ git reset --hard origin/master to reset HEAD to the remote branch. Substitute master for any other remote branch if you wish. That's it. I don't know if this is more difficult than re-cloning from scratch (especially if you're doing frontend and then have to reinstall node_modules and such…)
    - solardev 4y ago
      I don't know what the difference is, honestly :( I believe you, but I see both online and nobody seems to know the difference and it seems to work. Shrug? Most of my git life is copy pasting somebody else's commands because the model of it is really too complex for me. I've given up on caring... it's easier and faster to rewrite some code than deal with git's commands. Same thing for node modules, lol. Delete the folder and try again. If that still doesn't work, delete the lock file and try again. It's a terrible practice, I know, but it's the only thing that actually seems to work in my experience. EDIT: Apparently origin/master points to a specific branch. origin/HEAD points to the top of the "default" remote branch, which is often, but not always, master. Or something like that. I don't know for sure.
      - ziml77 4y ago
        Two things to make sense of how origin/HEAD is working. First is that HEAD always points to the commit that you currently have checked out. So, for example, if you have the master branch checked out, HEAD will be whatever is the latest commit in master in your local copy of the repository. Second is that to git there is no difference between the originating repository and your own. If you had your copy of the repo fully exposed, the remote machine that you cloned it from could push changes to your copy exactly the same way that you push changes to the remote machine. That second part is important because it means that the remote machine you're pulling from also has its own HEAD pointer. When you reset your state to origin/HEAD, you're telling git to set your own HEAD to point to the same thing as the remote machine's HEAD. This is very likely to be the same asking it to reset to origin/master because HEAD is probably pointing to master on the remote machine. The reason it's likely that HEAD=master is that in most circumstances the repo on the remote machine isn't manually being touched. When you first setup a repo there is only a single branch so that is what HEAD points to. If no one ever logs into the machine and executes a checkout command, that's what the server is going to continue to point to. However since there's no guarantee that HEAD=master, you shouldn't rely on that and instead always use the actual branch name.
        solardev 4y ago
frizlab 4y ago
I spend my life in git. I never ever had to just erase everything and clone again. I do not see a situation where it would be needed honestly.
- solardev 4y ago
  It's needed when you're somebody who doesn't want to spend their life in git and just want to undo a mistake.
  - 5e92cb50239222b 4y ago
    It's not going to help when one fucks up a complicated merge/rebase and can lose a ton of work if something goes wrong. Understanding what you're doing goes a long way. I've seen this a couple of times at $DAYJOB when someone doesn't understand how rebase works, smashes keys until it looks like they've achieved their goal, and then I have to ssh into their box and try to unravel the damage they've done, hoping that reflog has not been GC'd yet and there's something to revert to.
    - solardev 4y ago
      A 1000x this. I'm unfortunately that guy. I've learned never to use rebase and to copy and paste important code to a separate text editor (or use my IDE's separate undo cache) before trying a complex merge, and then just trying all over again if I fuck up. That's easier than trying to get git working right, lol. It feels like every git command is a PhD rabbit hole. All I know is that if I screw something in git, trying to fix it will just screw it up worse. Reset early and often and it usually works in the end. Lol, it's terrible...
kqr 4y ago
It's never easier to delete and re-clone. Proof: there's a reset command that does that but easier (once you know it.)

Depends. Sometimes it's easier to tear down everything and start from scratch.

leoff 4y ago

Isn't this what a `git reset --hard` does?

sethammons 4y ago
I've gotten out of sync with the remote where that would still fail and decided to just reclone. I think the reason it happened is git-history purists rewriting and pushing.
solardev 4y ago
That just resets to your last local commit. To sync back up to the remote, you need at least do a git reset origin/HEAD --hard (and capitalization matters, I don't know why). But that doesn't work if you rewrote history in some way (I'm not sure why that's even possible). In that case your local git can get pretty messed up, some gui tools (IntelliJ) start to bug out and fail to diff properly, and it's easier to just start over. After ten years of using git, I've more confused by it than ever. People here keep talking about mental models, but I've read a shit ton of docs on it and am still totally confused. Probably some of us just aren't smart enough lol.
- 5e92cb50239222b 4y ago
  Not sure what origin/HEAD is supposed to point to. HEAD is a ref that points to the tip of the current branch. It's not going to be available for remotes (it just doesn't make sense). To reset the current branch, you need to do two things: $ git fetch to fetch commits from the default remote and point remote branches accordingly, and $ git reset --hard origin/master to reset HEAD to the remote branch. Substitute master for any other remote branch if you wish. That's it. I don't know if this is more difficult than re-cloning from scratch (especially if you're doing frontend and then have to reinstall node_modules and such…)
  - solardev 4y ago
    I don't know what the difference is, honestly :( I believe you, but I see both online and nobody seems to know the difference and it seems to work. Shrug? Most of my git life is copy pasting somebody else's commands because the model of it is really too complex for me. I've given up on caring... it's easier and faster to rewrite some code than deal with git's commands. Same thing for node modules, lol. Delete the folder and try again. If that still doesn't work, delete the lock file and try again. It's a terrible practice, I know, but it's the only thing that actually seems to work in my experience. EDIT: Apparently origin/master points to a specific branch. origin/HEAD points to the top of the "default" remote branch, which is often, but not always, master. Or something like that. I don't know for sure.
    - ziml77 4y ago
      Two things to make sense of how origin/HEAD is working. First is that HEAD always points to the commit that you currently have checked out. So, for example, if you have the master branch checked out, HEAD will be whatever is the latest commit in master in your local copy of the repository. Second is that to git there is no difference between the originating repository and your own. If you had your copy of the repo fully exposed, the remote machine that you cloned it from could push changes to your copy exactly the same way that you push changes to the remote machine. That second part is important because it means that the remote machine you're pulling from also has its own HEAD pointer. When you reset your state to origin/HEAD, you're telling git to set your own HEAD to point to the same thing as the remote machine's HEAD. This is very likely to be the same asking it to reset to origin/master because HEAD is probably pointing to master on the remote machine. The reason it's likely that HEAD=master is that in most circumstances the repo on the remote machine isn't manually being touched. When you first setup a repo there is only a single branch so that is what HEAD points to. If no one ever logs into the machine and executes a checkout command, that's what the server is going to continue to point to. However since there's no guarantee that HEAD=master, you shouldn't rely on that and instead always use the actual branch name.
      - solardev 4y ago

frizlab 4y ago

I spend my life in git. I never ever had to just erase everything and clone again. I do not see a situation where it would be needed honestly.

solardev 4y ago
It's needed when you're somebody who doesn't want to spend their life in git and just want to undo a mistake.
- 5e92cb50239222b 4y ago
  It's not going to help when one fucks up a complicated merge/rebase and can lose a ton of work if something goes wrong. Understanding what you're doing goes a long way. I've seen this a couple of times at $DAYJOB when someone doesn't understand how rebase works, smashes keys until it looks like they've achieved their goal, and then I have to ssh into their box and try to unravel the damage they've done, hoping that reflog has not been GC'd yet and there's something to revert to.
  - solardev 4y ago
    A 1000x this. I'm unfortunately that guy. I've learned never to use rebase and to copy and paste important code to a separate text editor (or use my IDE's separate undo cache) before trying a complex merge, and then just trying all over again if I fuck up. That's easier than trying to get git working right, lol. It feels like every git command is a PhD rabbit hole. All I know is that if I screw something in git, trying to fix it will just screw it up worse. Reset early and often and it usually works in the end. Lol, it's terrible...

kqr 4y ago

It's never easier to delete and re-clone. Proof: there's a reset command that does that but easier (once you know it.)