4 ms·

I can't remember the last time I had to delete a repo, at most I do a hard reset to the head of the main branch. Still don't care and I'm doing well enough gett

I can't remember the last time I had to delete a repo, at most I do a hard reset to the head of the main branch. Still don't care and I'm doing well enough getting consistent maximum performance ratings at my job and building things in my own time. Sometimes a problem is not worth addressing, and part of being an effective software engineer on the whole is recognizing those times.

jenadine 2y ago
Both points are valid. But it shouldn't take hours to "fix" a repo in most cases. As you said: git reset. Anyway, I've been putting some of my repo in very bad states by doing git operation from different unix user that lacked the right permission to do all the writes leaving some corrupted objects and stuff which needs a bit more than just a reset to recover. Then it takes some time to recover, but that's because I also don't want to loose some hours of un-pushed work. Doing a delete of my repo could have been faster but I'd have lost some temporary branches and squashes and stuff that would also represent some work. But I think the original point is for people who are not even able to do a git reset.
matrss 2y ago
So, contrary to your own point, you did indeed put in some time and learned one of the ways you can fix a "fucked" repo, because it is more convenient to just 'git reset --hard main' than to delete and re-clone. There are some simple next steps to go from there: - notice that you don't have to reset to the main branch, you can put in any branch name - it doesn't even have to be a branch name, it can be any kind of reference to a commit - 'git reflog' is useful to find out a reference to a commit you recently were on, that you can then give to reset - you don't have to use --hard, I personally like using --keep, and sometimes you might want to keep local changes so you don't supply those options at all - ... What you already did is what Zambyte suggested you should do. Of course there is diminishing returns at some point, but that point comes way after 'git commit -am $msg && git push'.

jenadine 2y ago

Both points are valid. But it shouldn't take hours to "fix" a repo in most cases. As you said: git reset. Anyway, I've been putting some of my repo in very bad states by doing git operation from different unix user that lacked the right permission to do all the writes leaving some corrupted objects and stuff which needs a bit more than just a reset to recover. Then it takes some time to recover, but that's because I also don't want to loose some hours of un-pushed work. Doing a delete of my repo could have been faster but I'd have lost some temporary branches and squashes and stuff that would also represent some work. But I think the original point is for people who are not even able to do a git reset.

matrss 2y ago

So, contrary to your own point, you did indeed put in some time and learned one of the ways you can fix a "fucked" repo, because it is more convenient to just 'git reset --hard main' than to delete and re-clone. There are some simple next steps to go from there: - notice that you don't have to reset to the main branch, you can put in any branch name - it doesn't even have to be a branch name, it can be any kind of reference to a commit - 'git reflog' is useful to find out a reference to a commit you recently were on, that you can then give to reset - you don't have to use --hard, I personally like using --keep, and sometimes you might want to keep local changes so you don't supply those options at all - ... What you already did is what Zambyte suggested you should do. Of course there is diminishing returns at some point, but that point comes way after 'git commit -am $msg && git push'.