I learned that you can never make a mistake if you aren’t using git, or any other way for having access to old versions.
With git it is really easy to get back to an old version, or bisect commits to figure out what exact change was the mistake.
The only way I understand this joke is more about not wanting to be caught making a mistake, because that is pretty easy. In other methods figuring out who did the mistake might be impossible.
This is not about mistakes in the Git-managed code. This is about mistakes in the Git commands themselves. Anything that involves merging/rebasing/conflict resolution can potentially be botched. These mistakes are usually fixable, but:
Fixing it requires some Git proficiency behind the level of the common Git user.
If you don’t catch it in time, and only find the mistake when it’s deep in your layers of Git history - well, good luck.
Went to tech elevator boot camp, was a decent experience even if I don’t find myself doing exactly what I was expecting to do. Life is that way though.
Anyways, my first week I fucked some git stuff up so bad I became the go to guy when anyone had any git issues because I had to learn so much to undo my egregious error. I don’t remember now exactly what it was but it took some serious git magic to sort.
Just saying that point 1 is very true. And yeah don’t make mistakes in git.
Like accidentally committing multi-GB files and years down some poor mf (me in this case) has to figure out how to clear the files from history because the server is running out of space.
Short of manually deleting .git you can always find any commit, you can walk backwards through your reference lof if it comes to it, the only real risk is throwing out unstaged changes.
Hmm… I am using git for maybe 15 years… Maybe I’m just too familiar with it… and have forgotten my initial struggles… To me using git comes natural… And I normally pay a lot of attention to every single commit, since I started working on patches for the Linux kernel. I often rebase and reorder commits many times, before pushing/merging them into a branch where continuity matters.
You’re confusing errors in your code, and errors while doing some git command you thought you knew.
Lucky you, it’s clearly never happened to you because you don’t mess around with it.
Sure, I sometimes messed up with git, but a git reset , checkout, rebase or filter-branch (In the extreme cases) normally fixes it, but real issues are very rare. And I use git a lot… But only the CLI, maybe people have issues with GUIs?
Funny those are commands I avoid… They all have to do with editing history which I know there is a vocal group here that loves “clean” history but that isn’t what happened.
sure merge full features so you can roll back a feature… And if something is really off I might start from a snapshot commit and cherry pick/merge a bunch in but usually history is histoy… If submitting to a public project I may make a new branch with the cleaned version but why edit in line. That is risking issues.
Isn’t it the exact opposite?
I learned that you can never make a mistake if you aren’t using git, or any other way for having access to old versions.
With git it is really easy to get back to an old version, or bisect commits to figure out what exact change was the mistake.
The only way I understand this joke is more about not wanting to be caught making a mistake, because that is pretty easy. In other methods figuring out who did the mistake might be impossible.
This is not about mistakes in the Git-managed code. This is about mistakes in the Git commands themselves. Anything that involves merging/rebasing/conflict resolution can potentially be botched. These mistakes are usually fixable, but:
Went to tech elevator boot camp, was a decent experience even if I don’t find myself doing exactly what I was expecting to do. Life is that way though.
Anyways, my first week I fucked some git stuff up so bad I became the go to guy when anyone had any git issues because I had to learn so much to undo my egregious error. I don’t remember now exactly what it was but it took some serious git magic to sort.
Just saying that point 1 is very true. And yeah don’t make mistakes in git.
Like accidentally committing multi-GB files and years down some poor mf (me in this case) has to figure out how to clear the files from history because the server is running out of space.
Short of manually deleting .git you can always find any commit, you can walk backwards through your reference lof if it comes to it, the only real risk is throwing out unstaged changes.
Hmm… I am using git for maybe 15 years… Maybe I’m just too familiar with it… and have forgotten my initial struggles… To me using git comes natural… And I normally pay a lot of attention to every single commit, since I started working on patches for the Linux kernel. I often rebase and reorder commits many times, before pushing/merging them into a branch where continuity matters.
You’re confusing errors in your code, and errors while doing some git command you thought you knew. Lucky you, it’s clearly never happened to you because you don’t mess around with it.
Sure, I sometimes messed up with git, but a git reset , checkout, rebase or filter-branch (In the extreme cases) normally fixes it, but real issues are very rare. And I use git a lot… But only the CLI, maybe people have issues with GUIs?
Funny those are commands I avoid… They all have to do with editing history which I know there is a vocal group here that loves “clean” history but that isn’t what happened.
sure merge full features so you can roll back a feature… And if something is really off I might start from a snapshot commit and cherry pick/merge a bunch in but usually history is histoy… If submitting to a public project I may make a new branch with the cleaned version but why edit in line. That is risking issues.
👌