Your Git horror stories

Those first couple months learning git... yeah, it is weird, but once it clicks... you'll be surprised how truly simple it is.

The programming world would be awful without it

Learning git was like every other cool tech thing for me (including the fediverse). People explain it in such a convoluted way. It’s like they think you want to understand the deep theory of it before you get up and running!

Yes, git is more than just a “save box”, but really, new users should absolutely just think about it as a save box. Learn the fancy shit later.
- Honestly this is me. At this point I really should know better but I dont, and every tuorial seems to be speaking a whole new language. Any tips for where to learn this?
It was awful. The fact that SVN is still used terrifies me. People are actively choosing to live their lives like that
- Git was just released while I was in college, and I was in a group project that required us to use SVN. First job was a TFS shop. When git finally matured to the point that it couldn't be ignored anymore, life became much much more sane.
- Subversion has some features git lacks or lacked for a very long time (I think it has most now). The biggest being able to easily clone and work with a subset of the repository. That's Subversion's entire thing! Don't misunderstand, I prefer git and think it is better.
Yeah, remember the giant merge conflicts I had to deal with because of our lack of experience with git. One really learns how useful it is to split stuff into files with git. Also the headache of line breaks and case-sensitive paths.

No horror stories to tell, though. We all got through our first git learning experience without any major accidents. Once we had to re-up the remote repository from a dev machine, that was it.
I've recently worked on a project that was using Plastic SCM for version control, and omg the QoL is so insane on that one. It's such a shame that Unity are greedy as fuck and tend to ruin everything they acquire, the licensing costs for Plastic are awful.

For example - I really low how it tracks what was merged from where, so merges aren't just a single commits, and if you for example pull something into a feature branch you are working on, and then merge the branch into master, all of the files that come from your branch are listed as changes in the commit, but files that were merged into your branch are marked as "merged from XXX".

Having PRs (code reviews) integrated into the client is also nice, since you can just link changes with change requests directly, and since it was made for Unity projects it also pretty nicely handles large files.

It's a shame that Unity acquired it, though. My last experience with their business model was when I was looking for a streamed remote play solution for a Unity game - which was exactly what Parsec offered as a free open source SDK for years. Until Unity bought them and close-sourced it (or rather - changed to "contact us for access to the SDK)), and when I contancted them for the SDK for our small student's game, they were willing to cooperate and give us an access - if we pay them 1 000 000USD for it. Which they had the balls to ask for even though I've specificly mentioned in the email that we are a bunch of students who work on a small game in our free time, which I find really baffling :D

Joined on a project and the unsupervised junior devs had branches for each developer, even if they were working on the same features. They were copying and pasting each others code into their personal branches to stay up to date.

Spaghetti commits took a while to unwind.

As an old programmer who has used git since Linus whipped it up over one frenzied weekend after his spat with the evil BitKeeper and who has studied its mysteries since before most of you were born ... yeah just delete the damn project and download a new version.

Whelp, that's all the permission I need

The first place I worked, when I joined they were using git for their developers. That is - a bare git repo on a server that everyone has a key on so they can pull over ssh. No web UI at all.

The product was originally evolved from a 3rd party code base that was a all in one thing - backend and frontend together in the repo. But the company wanted their own UI so they created a new git repo for it to keep it isolated and decoupled. You know, so development and deployments were easier. But when I joined the two code bases were so intertwined the UI would not work if you did not have the backend checked out into the same location as the UI. No submodules, no dependencies coded anywhere - you just had to checkout both repos side by side to get it to work.

There was also this critical bit of software we had - developed by one guy in C (a language no one else really know). Now this was not a very complex application, but every billable event that we had went through it - so critical for us to be able to do anything. Its development process was, the guy would login to one of the production servers, change the code, rebuilt it and test it live on that server. Then when he was happy he would get a sysadmin to copy the code and rebuild it to all other nodes (this could be to over 2500 servers mind you). Ok, so this one was more horrifying due to the lack of any version control at all - though at least the code was backed up to a lot of servers...

Eventually I was tasked with getting that codebase in git and making it so we could rebuild it outside of production. This was a nightmare - had to learn how autotools worked in far more detail then I ever wanted only to find out the original developer had manually hand crafted some auto generated files.

Years later (after the company had good git practices and we had fixed all the issues above), this developer was working on a new project. Once I found out about it I took a look. He was using git this time. But the development process was, ssh to a prod server, edit the code live. Then wait for a cron job to run that dumped a bunch of store procedures from the database to the project, add all files, commit and push the code. I honestly don't know how anyone could get a standard workflow completely backwards...

On a nicer note, I have one about this one time git actually saved me weeks of work by accident. In uni I was working on some coursework - this was back when I was learning git and still trying to figure-out how best to use it. I was not using it correctly yet - for one I was not pushing code up to a remote yet, just working locally on my system. Well, one day I was doing some development and needed to clear out my build directory as I was seeing some weird behaviour. I switched over to the terminal that I keep inside that build dir and do a rm -rf *. Something I had done many times before to clear it out. But this time, I was in the wrong location, I was in the project root. And that was it, all my code was gone, weeks worth of work down the drain.

But then I noticed a .git folder still there. Turns out * does not expand hidden files. So a git checkout . and I managed to restore all files from my last commit - which was only a couple of hours ago. I don't think I had ever been so relieved before. I quickly pushed up that code to a remote repo.

Me doing a massive rebase

Find out at the end I royally messed up somewhere and it does not build at all.

I did not push changes to remote before rebaseing

I did not push changes to remote before rebasing? suprised picachu

You can still recover from that (reflog). But with limited experience, it's a chilling story :D
- wish I knew that back then
I was going to say.. I’m pretty good with git, and rebasing still gives me anxiety haha
- Honestly I am now a huge fan of having lots of tiny repositories. It simplifies ci/cd, forces you to split code into logical blocks with stable interfaces, and limits frequency and scope of conflicts.
- Prior to rebasing I still do git tag -f undo in case I screw up so I can do git reset --hard undo if I mess up. I don't understand reflog lol.
For any major operations like this, I always save the current commit with a tag. Very easy to get back to the original commit in case something blows up.

If I'm gonna merge some shit that'll probably have a bunch of conflicts, I'll create a throwaway "test-merge" branch because I'll inevitably fuck up the merge and even though I've used git for years I have no idea how to revert a merge andatthispointimafraidtoask.jpg

This guy gits it.
- Thanks, noob noob
git merge --abort
or, after it's been done, the nuclear option is to git reflog, find the state before your did the merge, and git reset HEAD@{4} or whatever HEAD@{#} it is.

Apparently git let's you push two completely independent histories into one repo if you force push and will happily let you go about your business until you try to merge.

I found this out when an intern copied the code, initiated a new repo, worked off that repo, force pushed into remote, kept working on his branches. Absolutely not his fault, he should have had help. But I had to edit history and rewrite the parent of a commit to unite the family lines!

Fun to learn that you can create that problem and also there's a "way" to fix it.

I believe I remember reading that in the official git repository a totally orphaned branch got merged. So if it can accidentally happen to the official team then I totally buy this.

On a college project, a friend was working on some changes on a branch which I proceeded to merge into my working branch. Visual Studio asked to stash, I said yes, his changes replaced mine, I panicked, raged, then redid the whole thing because I had no idea what a f***ing stash is.
On our final project, my friend and I had separate branches we were working on and since we both thought git was magic, we figured we'd just merge our changes the day we were supposed to submit. So naturally we had a merge conflict on a single file that he had since been restored (by re-commiting the old version, not git restore) which meant we had to spend that morning frantically recommitting? rebasing? (still not sure) the next 92 commits (I just checked the repo) and hoping we didn't break anything in the process.
There was that time at my job when I accidentally pushed some stuff I REALLY shouldn't have only to realize I had no force push permissions on a gitlab repo I created because it was under a group owned by the org. That one was there for months before I finally asked someone with the permissions to sort out (and they didn't forget to do it).

A developer had force pushed changes to remove some secrets from the repo. Then another developer who had missed the part about the cleanup saw the errors during git push and proceeded to just merge the changes. Cue absolutely fucked commit history where you had all commits twice with individual change commits sprinkled between both.

Only the usual "delete your local copy" story. Then at some point I learned that commits are just a bunch of nodes and branches are tags that move and nothing bad ever happened after that.

The real nightmares come from other systems, like IBM Rational Synergy. Bugs like not transmitting all lines of a file come to mind.

Not really a horror story because I fixed it with reflog, but it was a bit of a shock when we all suddenly couldn't push to the dev branch. Turns out one of the devs, who insists Git is just like SVN, decided to delete dev and push, and ignore the warnings. Apparently that's OK in SVN.

Alright, currently dealing with a CRLF issue from hell. The .gitattributes file says bat files should have CRLF endings but some template we use with backstage and cookiecutter makes the gradlew.bat file end up with CRLF line endings in the repository. Quick aside, whenever git is handling line ending conversions it sotres LF line endings inside the blobs then makes them CRLF on checkout. In the template repository everything is correct. But for some reason when you run the template the batch file has CRLF line endings in the repository.

Why does this matter? Because you'll have a totally fresh untouched repo and git will report a change in a file. You'llook at the doff and not see what is going on. Because you made no change. But git is trying to fix the problem of CRLF being in the repo when the attributes file says it needs to control the line endings.

You have to use the git cat-file command to see what is in the blob.

Yesterday I thought I narrowed it down to the Node project isomorphic-git but it actually seems to handle it correctly but I'm still suspicious.

Any advice is appreciated lol

I've had a similar issue before and the problem was that I had made the repo on linux, worked on it a bunch, copied it over to a different PC running windows, then copied it back. Found this on stackoverflow and it fixed it for me, but I've only tested it on linux (probably won't work on windows because grep). Hopefully it helps:

git diff -p -R --no-ext-diff --no-color | grep -E \"^(diff|(old|new) mode)\" --color=never | git apply
- That's the weird thing, everyone here uses Mac and the server running the template is Linux so this isn't a case of a Windows user forgetting to set autocrlf and even then it is in the git attributes file.
"checkout as-is, store as-is" - disables all conversions and just stores the file

I've often ended up guessing what things do and messing things up.

One example is when I couldn't remember the difference between git checkout -b and git checkout -B, so in my infinite wisdom I decided to use -B because surely capital letters are better! Tried using it to switch back to a branch, and... Yeah, that was annoying.

I would say capital letters tend to be more destructive. So I would not blindly useful them without knowing what they do first.
- the f (and r) in rm -rf: am I a joke to you

I really like GitHub Desktop; it handles well the confusion of terminal commands and UI.

GH desktop is great for the day to day stuff and I can always drop into a shell if i need to get my hands dirty

I relate to this pic so hard

So true. Never really used git professionally (not a programmer) just for hobby projects and I’ve had to delete projects a few times to get rid of errors.