Hacker News Reader

Comment by donatj | Hacker News Reader

> People who say "just delete the repo" when things go wrong really frustrate me

YES. Go be a baker or something! If you're going to be a developer you should generally speaking be willing to figure out what's wrong and how to fix it.

Know how your tools work. Bad carpenter what have you...

Also speaking of `git reflog` and such - I still stand by this article I wrote a few years back - https://donatstudios.com/yagni-git-gc

99% of people should just turn automatic `git gc` off. You don't need it. Turn it off and you never have to worry about losing work. It's there, you just have to find it.

View on HN

Git is an abysmal tool for many (most?) uses of it, but that unfortunately has become "standard". The sheer awfulness of git is witnessed by the amount of posts about it and little consensus on "best practices" (e.g., rebase vs merge).

So, I don't judge, but sympathize with people who just "delete the repo and start from scratch". Unintuitive, user-hostile tools call for heavy-handed solutions.

IME, most people are willing to learn something when they're shown the value for invested effort. That "delete the repo" is standard answer for fixing f*up, tells more about the tool than the people using it. (I.e. it requires disproportionately big investment of time for little value.)

I really don't agree with that. Git is a powerful tool with very few actual downsides, and the unwillingness of some developers to spend an hour learning how it works hurts them in the long-term.

It's like sticking to the text editing feature of your IDE because you can't be bothered to learn how it works. Sure, you _technically_ can do that, but you're losing on everything that makes an IDE useful and probably losing actual days or weeks worth of work because of that.

>the unwillingness of some developers to spend an hour learning how it works hurts them in the long-term

And that's the problem. Because every developer has spent an hour learning how it works by themselves but then each of them in completely different ways, from different sources, on different projects and workflows, some more correct than others, because there's not one single perfect ground truth way of using git in every situation, but git offers one million ways of shooting yourself in the foot once you land on the job, even after you think you learned git in that one hour.

And that IMHO is git's biggest problem: too powerful, too many features, too many ways of doing something, no sane defaults out of the box that everyone can just stick with and start working, too many config variables that you have to tinker with, etc. Case in point, just look at the endless debates in the comments here on what the correct git workflows are wand what the correct config variables are, nobody can agree on anything unanimously on what the right workflow of configs are everyone has their own diverging opinion.

I think you've just described why Git is so popular and literally everywhere.

Something being popular doesn't mean it's universally good everywhere and loved by everyone. Windows and Teams are also popular, almost every company uses them, that doesn't make them good. Diesel ICE cars are also highly popular in Europe even though they're much worse for our air quality and health. Do you see the issue with using popularity as an argument?

I've met many devs who hate git with a passion but they just have to use it because management said so and because evry other workplace now uses it, just like Teams and Windows. Not saying git is bad per se, just pointing out the crater of pitfalls it opens up.

Right but the world is bigger than corporate and yet I don't see anyone choosing anything else for their pet project large or small either. If Git was such a pain to use, wouldn't a lot of open source projects use something else? I know OpenBSD uses CSV, SQLite uses Fossil.. I can't honestly think of anything else non-Git right now that I use (I'm sure I'm missing some).

Years ago when private repositories were still a paid feature on GitHub, you could use Bitbucket, which had them for free, and offered Git and Mercurial. A few years later Bitbucket announced they were removing Mercurial support because "Mercurial usage on Bitbucket is steadily declining, and the percentage of new Bitbucket users choosing Mercurial has fallen to less than 1%".

https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...

>I don't see anyone choosing anything else for their pet project large or small either.

I also don't see anyone else choosing to breathing anything else than oxygen either. It's not like they have so many other options when the job market requires git and most coding tutorials also feature git and schools also use git, so the entire industry decided to use git despite other options existing.

Again, that doesn't mean git is bad or that is loved by everyone or that it's the best. Betamax also lost to VHS despite being technically superior. A lot of victories are won by the lesser product given enough inertia and being at the right time and the right place. Kind of how Windows and SAP got entrenched in the 90s. People and orgs were buying into it because everyone else was also using it so your only choice was to use it too no matter your own opinions on it. What were you gonna do? Piss against the wind and torpedo your hiring prospects by pigeonholing is some other "better" tool that nobody else uses?

I don't remember what VCS I used at my first job in the embedded industry but that one was hands down way better, easier and fool proof compared to git, with a nice GUI long before GIT GUI tools were even remotely good, it just didn't survive there long term because it costed a fuck tonne of money in licensing fees for the org. You can see where this is going, right? When it comes to bean counters, free beats paid every day regardless of most other arguments.

Also smoking was once both popular and everywhere. At least smokers enjoy it, I'm not sure anyone "enjoys" using git.

I'm sure I do.

Instead of turning off the automatic git gc, turn off the reflog expiration with:

  gc.reflogexpire=never
  gc.reflogexpireunreachable=never

I could spend hours of my workday on some uninteresting, irrelevant bullshit because the local repo is fucked, or just delete it and move on to solving actual problems and producing value. The choice is clear.

Or you could spend an hour or so learning to use git (or a git compatible vcs like Jujutsu) and then you never bork your repos, and instead spend your time solving actual problems and producing value.

What kind of pastries do you like?

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.

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.

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'.

>> Or you could spend an hour or so learning to use git

This is such nonsense. The git you can learn in an hour gets you exactly to the point where you end up in this "now what?" situation. Furthermore unless you're working through this more regularly than every 6+ months you're not going to remember how to fix it.

> Furthermore unless you're working through this more regularly than every 6+ months you're not going to remember how to fix it.

Take notes.

I have never deleted a repo because it's messed up. In the early days understanding what was wrong was sometimes challenging. But once I learned it it's just routine to clean it up. I do occasionally search stuff from my reflog or trial branches from years ago, no way I want to lose that opportunity.

One needs to learn full branch names and how the abbreviations used in daily life really work. A local branch called origin/foo can be confusing, especially after being pushed. And of course one needs to understanding the concept of remote branches in the first place, they are not really remote, typical poor git terminology.

For mass mess-ups in the work tree git status -s | grep ... oneliners are your friend.

Or you could actually learn git once and enjoy using a powerful tool without experiencing any of this friction. If you understand git you'll just know what to do when some weird thing happens.

I haven’t done that since my junior days. Do people really do this? I know Git’s UX is bad but wow.

Reply on news.ycombinator.com