THIS THING DELETED 3 MONTHS OF WORK!!!!
Other urls found in this thread:
github.com
twitter.com
>no backups
idiot
So does this mean that this guy had 3 months of work uncommitted? He's not even "using" version control then, really...
There is no cure for idiot.
3 months of code and not commit even once? I can't even close IDE after at least commit twice.
>AND TO THE GENIUS WHO IMPLEMENTED THIS:
>FUCK YOU FUCK YOU FUCK YOU FUCK YOU FUCK YOU
He may use in somewhere because Code will detect .git folder.
>microshit
found the problem
There was some suggestion that VSCode may have .git init'd the folder he had opened through an undocumented method/feature.
Either way, guys a fucking moron for not having source control/uncommitted/unbacked-up work..
>does not back up his shit for 3 months
>does not commit for 3 months
>starts playing with unfamiliar software
>presses buttons at random
he really did had it comming
The related, more serious discussion is interesting.
>github.com
>I don't think that having the equivalent of rm -rf as a GUI option is a good idea under any circumstances.
>LOL it's user error!!!
it's a shitty bug without a doubt, but if you're going to be messing with new source control shit in your existing projects, why would you NOT back them up elsewhere?
>Shitskin.
>Javascript
>html
wow we have a javascript guru here boys.
Is this you, OP?
I see no problem in the VS code behavior. It discards all changes when the user ask for it.
Is that bad? I do a ton of work on something and only commit when it's finally done.
in git it's good practice to commit when you're done with small bits that you're confident are finished, or at least at the end of your working day. it costs nothing, so you might as well.
Well at least he learned about source control from his mistake after the fact
Yeah that is terrible practice. Use separate issue-based branches and just make small commits on there. On completion you merge back to development.
USING MICROSOFT SHIT KYS YOU NIGGER
What is the point of version control if you don't use it?
With git, it is so easy to have several branches so you can work on it in increments.
Ideally, you should always be able to compile and run the code all the time and only merge with the main branch when your changes are ready.
Obviously git is meant to be used for large projects.
In situations where you only share code with yourself, the structure becomes less relevant.
I personally commit often but only pushes once in a while.
If you work with just one more person, you commit at least daily.
A commit should really only be about a single thing.
If you change 50 files in a single commit, you are doing something very wrong.
Hmm we should sue this is cray cray
>Windows has detected a non-Microsoft version control system.
>Are you sure you want to remove it?
> [Y]es / [P]roceed.
You don't see anything wrong in DELETING files it hasn't even touched, let alone created?
> absolute brainlets missing the point
You're as bad as people who leave low-haning GH comments just to farm thumbs ups.
Yeah, he was a dumbass for not having revision control. But that doesn't take away from the pants-on-head design choice he was so colourfully complaining about.
>discard all changes
Which word don't you understand?
i fucking said it was a shitty design, what more do you want?
>3 months of work
>I hadn't commited any of them to any repository.
THIS IS YOUR FAULT MICROSOFT HOW DARE YOU MAKE ME A RETARD
Usually that means "undo any unsaved changes", not "delete EXISTING files that haven't been touched this session".
Usually as in EVERY FUCKING OTHER PROGRAM EVER.
What's stopping him from just copying his stuff back from the daily backup?
Adding a file is a change. Would you contest that?
>Is that bad?
Unless you are working by yourself and manually manage backups (highly inefficient but maybe it soothes your autistic needs), yes
Repositories and proper branching are the best thing to ever happen to software development. So much freedom to fuck around, explore, learn and eventually be productive without ever being in danger of wrecking something.
Fairly sure the "LOST 3 MONTHS OF WORK!!!!!" was just a troll to get the issue noticed.
Normally issues like these get ignored as they are really a design choice not a bug.
What do you use git for then?
For when I change something noticeable. I don't do something like
>feature pt 1
>feature pt 2
>feature pt 3
I try to get something working completely before doing a commit.
Committing regularly isn't just about backups.
It also serves as documentation.
If you commit after each small change you make and you mention why you did it in the commit message you can later take any piece of code and see why it's there and if it changed over time why it had to change and how you changed it.
This can be extremely useful for debugging.
I would even say it's more useful than normal code documentation, while taking less effort to write.
He's a programmer, not a regular user. Design choices in software are no excuse to push random buttons and be an idiot.
for most VC systems that's how it is, but with git you're encouraged to commit often. So if you're working on a change that spans different screens it would be good practice to make a commit when you're done with one before moving onto the second, then committing after the second, etc. You can squash the commits and/or rebase to make everything neat when you push it. but whatever workflow works for you is what matters.
The idea is to create a branch for each new feature or big change you're making.
Then you commit in that branch as often as you like (I'd say at least a few times a day)
When you're finally done you merge your branch into the master branch.
End result for the master branch will be the same, but you'll have the benefit of regular backups and more useful commit messages.
>Then you commit in that branch as often as you like (I'd say at least a few times a day)
It's kinda tough though since you can't work on two branches at once with GitHub desktop unless you go through and uncheck every single file of one branch before every commit.
>GitHub desktop
WTF is that? Can't you just use git?
Why would you want to work on two branches at once?
You can easily switch between branches.
But having files open simultaneously on different branches seems insane to me.
monorepository user
That's not safe as something like OP can happen. What you should do is commit whenever you have a large number of changes/are done for the day and then rebase your commits before making a pull request.
>there are devs on the planet who don't use version control
please just kys we really don't need that shit in the industry
>click discard
>complains it discarded his code
lmao bootstrap soyboys
>GUIs are too complex for soyboys
normalizing tech use was a mistake
>CANNOT EVEN FIND THEM IN THE RECYCLE BIN!!!!
>I DIDN'T EVEN THOUGHT THAT WAS POSSIBLE ON WINDOWS!!!
Did this guy never use Windows before starting that 3 month, 5,000 file project?
I'll make partial commits when something is somewhat working, but parts are still fucked up, and just note what's fucked up and needs to be fixed in the commit message. The worst is when you spend hours getting something working, and then you realize the last hour of work was useless, but you can't go back because you haven't committed in forever.