Post the Sup Forums bane of your existence

...

Other urls found in this thread:

blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/
github.com/tpope/vim-fugitive
twitter.com/NSFWRedditGif

You obviously have never never had to work with perforce.

What's wrong with git?

How can Git be a bad thing. I use Git even on one-off projects that I'm working on alone.

Try TFS

Nothing wrong with Git. Better than CVS, TFS and other similar shit, a bit worse than Mercurial (tortoise 4life)

>site doesn't work correctly
>enables JavaScript on the main site
>Still broken
>Enables related sites too
>Still doesn't work
>Enables it for every site
>Site is still broken

git, or github?

>start a Git repository for a project
>give up on committing after a few days
>ended up pretty much rewriting the program entirely without a single commit

Just commit anytime you add a feature or something. It's useful because if you totally fuck something up beyond repair, you can just discard your changes and revert back to the previous commit.

I know, I just lack the discipline to commit regularly and add meaningful commit messages, especially since I'm the only person working on the project.

>I just lack the discipline to commit regularly

I know that feel bro

Just tell yourself you'll make it open source when it's done and that a thousand other people will look at your code. Gives you incentive to write cleaner code as well.

>not hosting all of your projects and pushing after every commit

>rebase it and claim that you wrote it all in one late night hacking session
heh...

Git is only a nightmare when you work with dozens of projects that are all dependencies to several other projects.

And even like this, I prefer it to SVN.

You wouldn't talk shit about git if you ever worked for a company that used p4 or subversion.

>>I know, I just lack the discipline to commit regularly and add meaningful commit messages
Just try being less of a brainlet. Then maybe people will want to work with you.

haha you used a meme word, upvote my fellow 4channer! :)

> Can't use git
Brainlets shouldn't post on Sup Forums.

In all seriousness it's really not that complex. Just read up on how it actually works.

If you're too lazy to commit, that's ENTIRELY on you. Editor plugins for git make the process practically seamless. If you're not committing that's a problem with you, not git.

>Editor plugins for git
This is a thing? Why not just :!git commit -m ""?

>have moderate anxiety disorder
>make a git account
>leave it for a bit
>make a public repo for something I'm toying with
>immediately gets followed by two friends
>panic
>don't touch it ever again

I understand they just wanted to share in what I was doing but it doesn't really matter what you understand.

Anyway my Sup Forums related nemesis is javascript's objects as functions as objects model. I've read plenty of descriptions and explanations and I still don't understand why.

...

JS bloatware everywhere on the interwebs

What merging tool do you use?

Git is great, but merging is pain in the ass

>merging is pain in the ass
Why? What's wrong with git merge?

This.

The ultimate jew-move. Take two completely unrelated disciplines and smash them together and the guys stupid enough to fall for it get paid less money.

Honestly, I say a full on revolt is needed to do away with devops. Shit is cancerous to IT shops everywhere.

Manually removing conflict markers

Bane?

How else would you resolve conflicts then? I certainly wouldn't want them to be automatic.

As someone that's come from years of experience doing it the old way: fuck you with a rusty rake.

Prima donna devs throwing code over the wall to ops and when whining when it doesn't work is the dark fucking ages. You write shit that breaks at 3AM, you take responsibility and answer the calls.

Using a tool that lets you pick one side or the other for each hunk of the merge conflict without requiring you to do manual character-by-character text editing.

Vimdiff, DeltaWalker, etc.

I've got 18 years of "the old way" so fuck you. Get some processes in place and a test environment. Devs shouldn't ever be allowed to push something into production until it's been thoroughly tested and signed off by CAB. That's the right way to do it, not have one person doing both jobs.

CABs are a meme, usually staffed by people without the requisite technical understanding (i.e. suits) and otherwise holding up continuous development.

Test environments are no substitute for throwing production traffic at a release. Good monitoring and competent staff who can quickly revert when problems are detected is better.

>>This is a thing? Why not just :!git commit -m ""?
Vim's git-plugin Fugitive has several useful features.

It lets you edit commit messages in a window in Vim, so you still have all your code open.
It lets you add or remove changes from the index very easily with just a simple keystroke
It makes it easy to diff a file on the fly when you're editing it.
Using the diff functionality, it makes it easy to stage some changes in a file and not others. This can be done manually using git-add --patch, but that's a massive pain in the ass. With fugitive you simply copy the text you want staged over into the staged side of the diff.
It makes it easy to toggle git-blame whenever you want so you know which coworker to abuse.

It has many other uses as well, but those are the ones I personally enjoy.

Why do companies choose those?

>>make a git account
There is no such thing. You're presumably talking about github or bitbucket. Those aren't git, those are services that git users can use to publish their code if they choose too.

Github is to git what SourceForge was to SVN.

Paid less?

All the devops positions I've come across are higher than ops pay.

Clueless execs making decisions about shit they don't have to think about the implications of, based on sales droids lies.

Amazon used to use Perforce before they began switching to Git. It was hell. Simply awful. Google also used to use Perforce. I believe they've also transitioned to Git by now.

Perforce was used by any company that had a MASSIVE amount of code and wanted to store all of it in a SINGLE repository. Perforce is the only revision control system that can handle hundreds of gigabytes or even terabytes of code in a single repo. Git melts down if you try to make a repo that big. But of course making a repo that big is insane and misguided. Per-project repos have many practical benefits. And Git works very well at that scale.

Perforce is a massive pain in the ass to work with. A very unpleasant experience.

Was about ready to sperg and then you caught the point at the end.

Putting all your shit in one basket might be marginally more convenient but it's a pain in the fucking ass to scale. Submodules and git-lfs will get you the rest of the way there.

git opens vimdiff for you

then you've had nothing but shitty companies to work at.

CAB's as well as any sort of code reviews prior to CAB should always be made up of technical people. Devs and sys engineers that can all weigh in on how a change will affect the environment.

Continuous development is bullshit as well. It's a lazy ass way of pushing code out as fast as possible without the proper checks in place to make sure you don't bring everything down because of a stupid ass mistake. I've worked on some absolutely huge projects requiring 3 or 4 huge ass companies working together and at no time was "Devops" ever considered a viable way to get anything done.

In that case, how is git the problem? Maybe I'm spoiled with Java's toolchain that ACTUALLY KINDA WORKS. (Never going back to shitty toolchains that don't work. The real problem is though that the second one part is fixed, people keep shitting on it to make it break. See: JavaScripts library ecosystem for perfect examples of this.)

EXACTLY THIS

>Perforce sales rep to Executive:
>"You guys have a lot of code right?"
>yeah, like 100 gigabytes and doubling every two years!
>"Well perforce is the only system that can handle repos that big. Why, if you used git for a repo that big, any command that walked the DAG would take weeks to complete!"
>gee, thanks mister sales rep, that makes a lot of sense to me!

meanwhile
>developers are thinking to themselves: "why does the sourcecode to eink kindles need to be in the same repository as CSS for the retail website?"

Code reviews, sure, but CABs are still considered harmful.

>continuous development is bullshit

Yeah okay grandpa.

>Git melts down if you try to make a repo that big
Read the Microsoft blog posts about their migration to Git and the customization that it required. It's a decent read.

blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/

But, realistically, putting the entire Windows OS into a single repository is just asinine.
They really should have put each component of the OS into its own repository, then wrote a build process that would fetch from each repository for a build.

Most of the time it's not even marginally more convienent because entirely unrelated projects that never link against each other or anything get shoved into one single repo. So that cute little CLI tool that you threw together with ruby and you want to share with your coworkers? That's in the SAME REPO as the retail website.

Insane to say the least. There is no reason for it, but many executives have fallen for the perforce meme.

For you.

pretty sure by default it doesn't open anything, it leaves the files in a conflicted state and requires you to edit them manually to remove the markers.

>They really should have put each component of the OS into its own repository, then wrote a build process that would fetch from each repository for a build.
Precisely right.
>then wrote a build process that would fetch from each repository for a build.
Amazon bit the bullet and did this. It works great.

As usual, Microsoft works harder not smarter.

They would have known this if they'd cared to look into why git was made in the first place

I've seen the opposite, especially for freelancers.

A senior level Linux/Unix admin can easily set a company back 6 figures. A good developer 80-90K. Devops guys walk through the door at $70-80K and do the job of both. If you're freelancing on sites like Upwork and Freelancer then expect to see $15-$20/hr for that stuff vs $30-$40/hr for a US based linux admin.

Yes but it does so with a new instance of Vim.

Using Fugitive, you can open vimdiffs in the copy of vim you're already working in. It's very convenient, you should give it an honest try.

github.com/tpope/vim-fugitive

Nobody but a sadomasochist chooses to use git without a diff tool configured.

No, CAB's keep stupid shit in check. CAB's help prevent bloat from unnecessary "features" that some idiotic ass dev decided was "cool" from ever seeing light of day because they ask "Why do we need this in the first place?" and the devs have to answer that question in a way that makes good business sense to all of the stakeholders. 99% of the time they can't, and that's why they're considered "bad" or "Harmful".

I actually work in an engineering company where most people's idea of source control is *.bak and only use git for my own code. So I don't have much use for anything other than snapshots, unless my understanding of a solo git workflow is flawed.

On the subject, there's actually a central SVN repo but I can't access it because the country HQ is based in put heavy controls on the export of the military things we work on. So I have to be sent things in emails and pray they're under 25MB.

>that some idiotic ass dev decided was "cool" from ever seeing light of day because they ask "Why do we need this in the first place?"

sounds like you need to stop letting pajeet write your code fampai

site?

I worked in defense. Pajeet was never allowed to work on code. Nor was Xaioyunping.

>CAB's help prevent bloat from unnecessary "features" that some idiotic ass dev decided was "cool" from ever seeing light of day because they ask "Why do we need this in the first place?"

You're literally not doing devops, then. Why did "cool" unncessary "features" make their way into the release backlog without a project manager catching it? Why did they pass code review? How did they get any time allocated to them? What user story was being addressed?

There's already a countermeasure, you just prefer ancient bureaucracy instead.

Oh shit that explains a lot. Bureaucracy is the only way you guys get off.

correction: Pajeet and Xiao needed to have been naturalized before working on anything. We had ZERO H1B's working for us.

>defense contractor
>lecturing other people about dysfunctional development practices

I no longer work in defense, but the private sector companies I worked for were harder on devs. I worked for a major resort/hospitality company on the security team and our input was typically the nail in the coffin for many a stupid idea. Sure they had use cases for some of that shit, but the moment any of us say where the big fat security hole was is went down in flames.

>So I don't have much use for anything other than snapshots, unless my understanding of a solo git workflow is flawed.
Using git solo with Fugitive can still be very useful.

For instance it allows you to easily commit some changes in a file but not others, so you can easily create clean commits that only have one feature in them. This makes it easy for you to roll back changes you've made.

>I actually work in an engineering company where most people's idea of source control is *.bak and only use git for my own code.
Be the change you want to see. Set a good example for others to follow.

Your dev either have to much free time or a bunch of intern with infinite excess energy to do stupid shit. Who is insane enough to code "extra feature" without discus with other? Did they even get paid for it?

The problem is separate a very big project to smaller component can driven a rock insane.
And while these project get updated regularly? Just thinking about it make me want to kill myself.

>lack the discipline to commit regularly
It's like 2 lines in the terminal.
>meaningful commit messages
Just list the new feature you added, or the bug(s) you fixed, you don't have to write an essay.

they're called submodules, user.

Then fucking learn the discipline. Don't touch the code until you have an idea of what it is you mean to accomplish, and don't make any changes other than those directly in furtherance of your goal.

And if you fuck up and do it anyways, use git add -p to at least only stage/commit the hunks so the history is still logical.

Really? Git?

Let me tell you about Enterprise Java Beans 3.0
You don't know PAIN. You do not know SUFFERING. You do not know endless needless fucking pedantry, until you know EJB 3.0.

Not 3.2, 3.0 because FUCK YOU.
I hate legacy projects that went full enterprise needlessly. But not so full enterprise that the system is performant and secure.

xda-developers for example
The login button does not work on firefox 54 or the latest ice cat mobile version, when you press it, it sends you to forum.xda-developers.com/#

I had to use puffin to log in since it was broken on my PC browser and on icecat too
>it could have been my hosts file though, I only disabled every addon and tried with another browser I never tried using the default hosts

It's a big butt.

>subversion
>There's a few different repos, makes sense with all the different dev projects going on
>There's also a couple repos for documents, oh god
>Crap shoot whether anything is actually there
>Have to manually update to get new files, will likely forget

This shit is fucking gay yo, some grognard was waffling to me about a system setup that I didn't have creds for and documentation was missing, because he didn't fucking commit the document.

Why the holy shit are we doing this

...

>No, CAB's keep stupid shit in check.
kek

>ctrl+f "cad"
>phrase not found
curious