At least they were humble and didn’t blame it entirely on Cursor… they also blamed Claude.
this guy would have force pushed onto main about 10 mins after this if he did have git
Tbf you have to do that for the first push, if a Readme file was autogenerated
You don’t if you just clone the repo you created.
Huh? I’m talking about existing code being in a dir, then initting a git repo there, creating a pendant on your hoster of choice and then pushing it there. Wouldn’t cloning the repo from step 3 to the code from step 1 overwrite the contents there?
There are multiple solutions to this without using --force.
Move the files, clone, unmove the files, commit, push being the most straightforward that I can summon at this time… but I’ve solved this dozens of times and have never use --force.
If your remote is completely empty and has no commits, you can just push normally. If it has an auto-generated “initial commit” (pretty sure Github does something like that), you could force push, or merge your local branch into the remote branch and push normally. I think cloning the repo and copying the contents of your local repo into it is the worst option: you’ll lose all local commits.
True, in the situation with a local history maybe it’s worthwhile to --force to nuke an empty remote. In that case it is practical to do so. I just typically like to find non-force options.
If it’s a single, generated, “initial” commit that I actually want to keep (say, for ex I used the forge to generate a license file) then I would often rebase on top of it. Quick and doesn’t get rid of anything.
You can also just tell GitHub to not do that.
Yeah, I was thinking of a new repo with no existing code.
In your case you’d want to uncheck the creation of a readme so the hosted repo is empty and can be pushed to without having to overwrite (force) anything.
deleted by creator
“Developer”
“my” 4 months of “work”Those are the ones easily replaced by AI. 99% of stuff “they” did was done by AI anyway!
Before Git, we used SVN (Subversion), and CVS before that. Microsoft shops used TFS or whatever it’s called now (or was called in the past)
Wasn’t it Visual SourceSafe or something like that?
God, what a revolution it was when subversion came along and we didn’t have to take turns checking out a file to have exclusive write access.
Visual SourceSafe
Yes! That’s the one I was struggling to remember the name of. My previous employer started on Visual SourceSafe in the 90s and migrated to Team Foundation Server (TFS) in the 2000s. There were still remnants of SourceSafe when I worked there (2010 to 2013).
I remember TFS had locks for binary files. There was one time we had to figure out how to remove locks held by an ex-employee - they were doing a big branch merge when they left the company, and left all the files locked. It didn’t automatically drop the locks when their account was deleted.
They had a bunch of VB6 COM components last modified in 1999 that I’m 80% sure are still in prod today. It was still working and Microsoft were still supporting VB6 and Classic ASP, so there wasn’t a big rush to rewrite it.
Welcome to my world… our new lead architect has mandated that we move everything from TFS to GitLab before the end of the year. I hope it comes true.
Yeah VSS was the predecessor to TFS, and now TFS is called Azure DevOps… whatever the fuck that means, Microsoft needs to get it together with product naming. Anyway TFS sucks major rotten ass. I have my problems with git - namely user friendliness - but TortoiseGit has put all those troubles to rest.
Nothing like that can fix TFS.
I started at a company that uses ADO (migrating to GitHub this year) and it took me like 20 minutes to figure out how to change repositories in the UI… idk how they built something that unuser friendly
I could go all day with my grievances… For some fucking reason, Team Foundation Server thought it would be a good idea to model their source control on folders and files rather than atomic nodes of changes like git.
I’m sure someone thought this was intuitive, but it falls apart once you realize you can check in cross-branch or even cross-project files into a single changeset. This allows you to easily pollute projects you’re working on but didn’t intend to modify yet, if you forgot to exclude their files. And then, when your code reviewer checks the history of the project folder you modified, they don’t even notice all the files you changed that WEREN’T in that folder but were part of the same changeset. So you pass your review, and all the sudden there’s unwanted, unnoticed, and untested changes in some other project, with a nice code review stamp on them!
And the entire checkout/checkin system is just flipping the read-only flag on the files in file explorer. It’s the most amateurish shit. If you edit a file in an open, active project, the file gets checked out automatically. But if you’re editing loose scripts that aren’t part of a bespoke SLN or CSPROJ, you have to check those out manually… which it will only tell you to do once you try to save the file.
And then Visual Studio cannot understand that I might need to switch regularly between 2 types of version control systems. If you’re not on the same VCS plugin when you want to open a recent project on it, it doesn’t automatically switch it for you, it just refuses to load the project. The only way to reliably to switch is by going into the options menu, changing it there, THEN loading the project.
git is practically made of grease compared to how stuttery and clunky TFS is. I’ll shed no tears for the fossils who are having a hard time learning git, they will be better off whether they realize it or not.
I thought mercurial was older than git, but apparently it’s 12 days younger.
And throughout it all was the tried and true v3.0-final-UPDATED-4
The best is when the version also had the name of an ex employee on it.
if it doesn’t have both _draft and _final in the name and at least one (1) in it, are you even really versioning?
A place I worked at did it by duplicating and modifying a function, then commenting out the existing one. The dev would leave their name and date each time, because they never deleted the old commented out functions of course, history is important.
They’d also copy the source tree around on burnt CDs, so good luck finding out who had the latest copy at any one point (Hint: It was always the lead dev, because they wouldn’t share their code, so “merging to main” involved giving them a copy of your source tree on a burnt disk)
20+ years on and I still have some unresolved Clearcase trauma.
eh heheh we still use clearcae hehe … heh
TFS actually moved its core version control to Git in 2013 and was later was rebranded as Azure DevOps a few years ago
Thank god, we STILL use TFS at work, and its core version control model is reeeeeally fucking awful.
deleted by creator
CVS was, for the longest time, the only player in the FLOSS world. It was bad, but so were commercial offerings, and it was better than RCS.
It’s been completely supplanted by SVN, specifically written to be CVS but not broken, which is about exactly as old as git. If you find yourself using git lfs, you might want to have a look at SVN.
Somewhat ironically RCS is still maintained, last patch a mere 19 months ago to this… CVS repo. Dammit I did say “completely supplanted” already didn’t I. Didn’t consider the sheer pig-headedness of the openbsd devs.
Pretty sure GTA V use(d) SVN or something like that. I remember reading the source code and being surprised that they didn’t use GIT.
Game developers often use Perforce instead of Git. Maybe it was that?
You definitely need something else than git for large assets, yes, its storage layer is just not built for that and they way art pipelines generally work you don’t get merge conflicts anyway because there’s no sane way to merge things so artists take care to not have multiple people work on the same thing at the same time, so a lock+server model is natural. Also, a way to nuke old revisions to keep the size of everything under control.
That’s very possible.
We still use RCS at work. For config files for our network monitoring. Works fine still.
“We’ve always done things this way, we ain’t changing!” - some folks in the Foss community, like those RCS maintainers
which is about exactly as old as git.
Wdym by that?
And Claude, off course.
Before that, it was RCS, released in '82.
Or gnu arch
deleted by creator
Ah yes, the elusive AI “programmers”.
The vibes were off.
Yeah this what you get when you code based on vibes.
I just want to pause a moment to wish a “fuck you” to the guy who named an AI model “Cursor” as if that’s a useful name. It’s like they’re expecting accidental google searches to be a major source of recruitment.
they are the first thing that comes up when searching “cursor” in both ddg and google, so I think they’re doing ok
Yes, that is the problem I wanted to acknowledge, thank you for clarifying.
Forget git. Sending zip files into discord once in a while it the way to go.
deleted by creator
I’d feel sorry for them. My personal projects will only harm them.
Not if you encrypt the zip.
It’s a scary amount of projects these days managed by a bunch of ZIP files:
- Program-2.4.zip
- Program-2.4-FIXED.zip
- Program-2.4-FIXED2.zip
- Program-2.4-FIXED-final.zip
- Program-2.4-FIXED-final-REAL.zip
- Program-2.4-FIXED-FINAL-no-seriously.zip
- Program-2.4-FINAL-use-this.zip
- Program-2.4-FINAL-use-this-2.zip
- Program-2.4-working-maybe.zip
- Program-2.4-FINAL-BUGFIX-LAST-ONE.zip
- Program-2.4-FINAL-BUGFIX-LAST-ONE-v2.zip
I did that with documents in my Uni years.
By the end, I was using ISO timestamps.If we’re talking actual builds then zip files are perfectly fine as long as the revs make chronological sense.
I’m not. I’m talking about in companies where dev A wants dev B to do some work, but they don’t use git or any kind of source control, so you email over a cursed ZIP file, then dev B does the work and sends it back with a different name. It’s a highly cursed situation.
Yeah that’s bad.
You need a USB C “Power Ctrl+Z” key. Unlike the regular Ctrl+Z key one of these bad boys is capable of reversing edits across system reboots until as far back as when you originally plugged it in.
From what I understand, you could un ironically do this with a file system using BTRFS. You’d maybe need a
udevrule to automate tracking when the “Power Ctrl+Z” gets plugged in.
subversion. those were the days…
Was my first experience with source control, a bunch of Gary’s Mod mods were distributed that way, think I recall wiretool doing that, spacebuild was for sure, predated my work use by like 5ish years.
I didn’t hate it but definitely prefer git, but I’ll take literally anything over not having it,
Haha I literally thought of this exactly, Garry’s Mod. Why do I need this tortoise crap, just gimme a zip. Ah, summer child.
We still use it in my job.
Pls help.
Just a heads up, it you don’t know how to use cli git in 2025 you’re probably a shit developer. There are undoubtedly exceptions, but I would argue not knowing version control intimately makes you a bad developer.
deleted by creator
Mate… Theres maybe like 5 “git + singleword” commands that cover 99.999% of all of your uses of git. Its really not hard.
The fact that you don’t already know why and are dependent on GUI tools that you don’t fully understand is the reason that you’re probably not a very good developer.
Git is incredibly powerful. Knowing why and how is infinitely valuable. Nothing about git cli is archaic or even particularly difficult to understand. Also the man page is very excellent.
deleted by creator
I said that you are probably not very good. Your lack of git knowledge and your seeming inability to learn git means that you’ll likely never be able to function effectively in a development team and will only succeed in holding everyone back. Your lack of knowledge of version control overall is a massive point against you from the outset.
If you’re a solo developer and never need to collaborate with other developers then good for you, but you lack of version control knowledge means that you’ll also probably end up being one of the ones crying that you lost 6 months of work because of stupid reason x y or z.
Read up on fallacies, I did not use one. Your pathetic attempt to shoehorn anything that I said into a no true Scotsman fallacy just shows that you also have poor communication skills.
Holy fucking shit. I didn’t even catch the bit at the end. You really think that cli arguments are archaic??? I’m going to go ahead and assume that regex has you scared shitless as well. Fuck me, you are not a good developer.
Sidenote, something that will help you understand regex and you can test your strings against it in realtime, look up https://regexr.com/
Because they are universally incapable of coming anywhere close to the full power of git.
I can’t tell you how many times I’ve had GUI-only people ask me to unfuck their repo (fortunately not at my current job, because everyone uses the CLI and actually knows what they’re doing). It’s an impedance to actually learning the tool.
Ultimately any GUI is a poor, leaky abstraction over git that restricts many of the things you can do for little actual benefit.
Most cli stuff is a lot easier than programming. If you can’t use cli then by definition you’re a shit programmer.
Of course if you simply don’t want to use cli that’s a different matter.
There’s nothing ‘archaic’ about git’s CLI. I think you might just be opposed to CLI’s in general, which is fine for a regular computer user, but paints a grim picture of your competency if you’re a developer.
That seems unnecessarily harsh.
I find the built in controls with visual studio supremely convenient.
After using git init --bare for the remote repo I use the built in git controls for branching and switching out as well as syncing and pushing. Why not, the button is right there and it’s literally faster.
The difference is that PRESUMABLY you aren’t utterly dependent upon it. If vscode utterly fucks your repo with a shit command, you’ll not really have any trouble fixing it. That’s the huge difference. The point is not that all GUI controls are always bad all of the time, the point is that you need to know what the hell you are doing in git as a basic tenant of developer competency.
As someone using git for the last 10 years by now: you’re wrong. No UI has managed to give me access to all the fuckery I often do very quickly on the command line. I was honestly surprised to see IntelliJ nowadays supports an interactive rebase, but reflog, which should be a basic git feature, is still not widely supported in most IDEs in 2025. Or adding, resetting or checking out files with regex. Setting up and modifying lfs. And these are all basic features, good luck doing something like using branch~n syntax for some of the operations etc.
Git UI is shit and will be for a long time.
Why learn a GUI that can change from release to release when I can learn a CLI once and be done with it. An additional plus is that CLIs are easier to script and automate.
Acts like SVN and CVS didn’t exist
svn was invented in 2000
CVS was invented in 1986
Now Target owns them, I think.
I remember SVN
