Comment by antithesis-nl
2 days ago
Yeah, please don't create sites like this. Just... don't.
Any, and I mean any "in case of a Git problem, just do this" recipe is wrong, often in very subtle ways. So, my advice: in case of a Git problem, contact the help channel provided by the organization hosting your Git repository. They'll help you out! And if it's your personal-I-am-truly-the-only-human-using-this repository? Just recreate it, and save yourself the pain.
Source: I'm part of the team behind the #githelp channel in many $DAYJOBs, and we know how hard things are. You committed an unencrypted password file, or worse, your entire 'secret' MP4 collection to our monorepo? Sure, just let us know! Pushed your experimental branch to master/main/head/whatever? We'll fix it!
Just don't ever, for whatever reason, run that-chain-of-commands you found on the Internet, without understanding what they do! In most cases, your initial mistake can be undone pretty quickly (despite requiring nonstandard tooling), but once you're three levels deep and four days later, not so much...
I've been using git for at least 6 years now, maybe 10.
Sites like this are a great aid to remembering how to deal with certain situations. And yes, I understand what the commands do, but that doesn't mean I always could, or always want to, put together the series of steps from scratch.
And also, we self-host our own gitea hosting because we're not getting sucked down by yet another hosting debacle (old enough to have suffered under sourceforge, and don't plan on getting in the same situation again). For git hosting just as much as everything else on line, if you're not paying for it, you're not the customer.
> For git hosting just as much as everything else on line, if you're not paying for it, you're not the customer.
Yeah, lovely trope, but I'm literally talking about organizations hosting their Git repos on a file share here.
Why would you ask employees of a file hosting service about how to use git?
We’re not all working at $bigcorp with dedicated help teams. Sites like this are great and have helped me many times!
What happens when you are the help team and it's the first time something goes wrong?
A 'team', by definition, consists of more people than 'you.'
And, by the time a '#githelp team' is formed, it's to address patterns to which there are known solutions.
One of the many problems with Git, is that these solutions depend very, very much on the structure of the repo and the common practices of its users.
So, instead of executing random commands from the Internet, just ask. Please! Or, if there's truly nobody going to be around, give in and recreate the repo. You'll save yourself so much pain in the long run...
1 reply →
OK, so you've truly screwed up your your personal/small-team repos to the point of requiring poorly-understood command sequences from the Notoriously Reliable Internet more than once?
I applaud you for your honesty, but... Really?
I don't understand your surprise or disbelief. I would imagine most devs have been there. As evidence: just look at Stack Overflow, and compare it to what it's apparently intended to look like and how it's supposed to work (as a denizen of meta.stackoverflow.com I am quite familiar with this struggle).
Bro, really, self-taught people with a bare minimum understanding of the tools they use are super normal, and when they get into a pit they have to fix it themselves.
Although to your point folks would be better served carefully reading the docs / git book than googling a specific solution to their specific error code.
15 replies →
Yes. I think the ratio of small-team repos this describes is close to 100%. You seem to have a certain idea of how repos are managed. I don't think it's very representative of reality.
Recipes like these aren't useless, but yes, they really need to be prefixed with whether they expect to start from a clean work tree and empty staging area. Or describe what they'll do to uncommitted changes, both staged & unstaged. Otherwise they pose a substantial risk of making the problem worse.
> "... or worse, your entire 'secret' MP4 collection to our monorepo?"
Oh no, that poor soul...