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.

[–] LePoisson@lemmy.world 5 points 1 day ago

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.

[–] rikudou@lemmings.world 2 points 1 day ago

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.

[–] offspec@lemmy.world 1 points 1 day ago

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.

[–] cmhe@lemmy.world 0 points 1 day ago* (last edited 1 day ago)

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.