Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "git. pr"
-
Coworker in my team recently said to boss:
"Thanks, this conversation with you has taught me so much about single-threaded blocking I/O"
Some random PR comments from our company's repository:
"Are you insured? I hope you are insured"
"Learning git is not that difficult. You only need one command: git reset --hard"
*Link to amazon for dog poop bags*
"Please clean up your shit, before I step in it"
"Have you thought about a career in sales? At least there you might sell your bullshit"2 -
!rant
This was over a year ago now, but my first PR at my current job was +6,249/-1,545,334 loc. Here is how that happened... When I joined the company and saw the code I was supposed to work on I kind of freaked out. The project was set up in the most ass-backward way with some sort of bootstrap boilerplate sample app thing with its own build process inside a subfolder of the main angular project. The angular app used all the CSS, fonts, icons, etc. from the boilerplate app and referenced the assets directly. If you needed to make changes to the CSS, fonts, icons, etc you would need to cd into the boilerplate app directory, make the changes, run a Gulp build that compiled things there, then cd back to the main directory and run Grunt build (thats right, both grunt and gulp) that then built the angular app and referenced the compiled assets inside the boilerplate directory. One simple CSS change would take 2 minutes to test at minimum.
I told them I needed at least a week to overhaul the app before I felt like I could do any real work. Here were the horrors I found along the way.
- All compiled (unminified) assets (both CSS and JS) were committed to git, including vendor code such as jQuery and Bootstrap.
- All bower components were committed to git (ALL their source code, documentation, etc, not just the one dist/minified JS file we referenced).
- The Grunt build was set up by someone who had no idea what they were doing. Every SINGLE file or dependency that needed to be copied to the build folder was listed one by one in a HUGE config.json file instead of using pattern matching like `assets/images/*`.
- All the example code from the boilerplate and multiple jQuery spaghetti sample apps from the boilerplate were committed to git, as well as ALL the documentation too. There was literally a `git clone` of the boilerplate repo inside a folder in the app.
- There were two separate copies of Bootstrap 3 being compiled from source. One inside the boilerplate folder and one at the angular app level. They were both included on the page, so literally every single CSS rule was overridden by the second copy of bootstrap. Oh, and because bootstrap source was included and commited and built from source, the actual bootstrap source files had been edited by developers to change styles (instead of overriding them) so there was no replacing it with an OOTB minified version.
- It is an angular app but there were multiple jQuery libraries included and relied upon and used for actual in-app functionality behavior. And, beyond that, even though angular includes many native ways to do XHR requests (using $resource or $http), there were numerous places in the app where there were `XMLHttpRequest`s intermixed with angular code.
- There was no live reloading for local development, meaning if I wanted to make one CSS change I had to stop my server, run a build, start again (about 2 minutes total). They seemed to think this was fine.
- All this monstrosity was handled by a single massive Gruntfile that was over 2000loc. When all my hacking and slashing was done, I reduced this to ~140loc.
- There were developer's (I use that term loosely) *PERSONAL AWS ACCESS KEYS* hardcoded into the source code (remember, this is a web end app, so this was in every user's browser) in order to do file uploads. Of course when I checked in AWS, those keys had full admin access to absolutely everything in AWS.
- The entire unminified AWS Javascript SDK was included on the page and not used or referenced (~1.5mb)
- There was no error handling or reporting. An API error would just result in nothing happening on the front end, so the user would usually just click and click again, re-triggering the same error. There was also no error reporting software installed (NewRelic, Rollbar, etc) so we had no idea when our users encountered errors on the front end. The previous developers would literally guide users who were experiencing issues through opening their console in dev tools and have them screenshot the error and send it to them.
- I could go on and on...
This is why you hire a real front-end engineer to build your web app instead of the cheapest contractors you can find from Ukraine.19 -
Coworker: You've merged the wrong PR. It is broken.
Me: is it marked as broken? Is there a mail marking it as broken?
Coworker: yes. I wrote something in the chat.
Me: 🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕
I do NOT read and click every brain fart from the chat. I had the PR (as reviewer and dependent developer) open on my desk and waited for the coworker to fix his merge conflicts.
OK then, try to revert. Git reset hard. Push -f. Policy does not allow master modification. 🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕🖕
Fuck this company. Fuck the policies. Fuck them all with a chainsaw. Forced me to work 2 weeks more. 17.04 should have been my last day at this circus. Let 3 other guys go to vacation while I have fix their management's mistakes. Fuck. You. All. Eat shit and suffocate in piss.8 -
I once reviewed a Pull Request made by a fairly junior developer. They had joined recently, and this was one of the first times they had to touch a bigger part of the code.
Due to a mix of inexperience, new (to them) coding standards and lack of git knowledge, they ended up with a mess of a PR, with a few thousand lines changed, and no way to split it off.
I ended up spending the best part of a day reviewing the whole thing and requesting changes.
Even with the long list of improvements, however, I wasn't sure they would get the magnitude of their fuckup.
So I decided to use a real-world, palpable way to show them what they had done: I went and printed the github diff for that PR. It rendered the glorious amount of 73 pages.
I'll never forget their face, and those of their teammates, when I barged into the room with a thick wad of paper and deposited them on their desk.
At least it worked. I never saw another big, ill-thought pull request from them again.3 -
TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.
I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.
FF to today:
- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"
And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.11 -
This is something that happened 2 years ago.
1st year at uni, comp sci.
Already got project to make some app for the univ that runs in android, along with the server
I thought, omg, this is awesome! First year and already got something to offer for the university 😅
(it's a new university, at the time I was the 2nd batch)
Team of 12, we know our stuffs, from the programming POV, at least, but we know nothing about dealing with client.
We got a decent pay, we got our computers upgraded for free, and we even got phones of different screen sizes to test out our apps on.
No user requirement, just 2-3 meetings. We were very naive back then.
2 weeks into development, Project manager issues requirement changes
we have a meeting again, discussing the important detail regarding the business model. Apparently even the univ side hadn't figure it out.
1 month in the development, the project manager left to middle east to pursue doctoral degree
we were left with "just do what you want, as long as it works"
Our projects are due to be done in 3 months. We had issues with the payment, we don't get paid until after everything's done. Yet the worse thing is, we complied.
Month 3, turns out we need to present our app to some other guy in the management who apparently owns all the money. He's pleased, but yet, issued some more changes. We didn't even know that we needed to make dashboard at that time.
The project was extended by one month. We did all the things required, but only got the payment for 3 months.
Couldn't really ask for the payment of the fourth month since apparently now the univ is having some 'financial issues'.
And above all: Our program weren't even tested, let alone being used, since they haven't even 'upgraded' the university such that people would need to use our program as previously planned.
Well, there's nothing to be done right now, but at least I've learned some REALLY valuable lesson:
1. User Requirement is a MUST! Have them sign it afterwards, and never do any work until then. This way, change of requirements could be rejected, or at least postponed
2. Code convention is a MUST! We have our code, in the end, written in English and Indonesian, which causes confusion. Furthermore, some settle to underscore when naming things, while other chooses camel case.
3. Don't give everyone write access to repository. Have them pull their own, and make PR later on. At least this way, they are forced to fix their changes when it doesn't meet the code convention.
4. Yell at EVERYONE who use cryptic git commit message. Some of my team uses JUST EMOTICONS for the commit message. At this point, even "fixes stuffs" sound better.
Well, that's for my rant. Thanks for reading through it. I wish some of you could actually benefit from it, especially if you're about to take on your first project.3 -
Why do people have to lie? I am seriously getting tired of it.
Context: While I was on vacation the company hired some guy we’ll call Bob.
Bob is a senior with 10+ years of experience. 5 of those years in React (supposedly).
I got back from vacation and was told I’d be working on a project with Bob.
I’ve worked in teams before so I thought no problem.
Now I am aware that different people have different styles, so that’s why we agreed on a lint config with some fancy git hooks.
I was excited at first because the project actually seems nice, but my excitement soon turned into terror.
First of all, Bob doesn’t seem to understand Git…fair enough, I’ll give him a quick guide…
Mf calls me at 11pm on a Friday because he can’t push because the tests are failling.
Now tests. Bob doesn’t write those. Great.
We had created a few components to use throughout the project.
Bob seems to consistently forget what components are and why you write them and just imports the defaults from the UI library we’re using.
Bob also has a kink for hardcoding values for some reason.
I talked to Bob multiple times about this and he just tells me he’ll change it but in the end the PR stays open for 5 days, before it’s actually me who goes in and fixes it. Oh and yeah this shit keeps happening over and over again.
Now I know some of us devs hate meetings but for the love of God Bob just show up. You don’t even have to speak. Or at least answer a message that corresponds to the working hours and not in the middle of the night.
I am getting tired of this behavior and am seriously holding back from reporting this to the management. It’s been a month and I am seriously worried about the project. I have my own stuff to do but it takes time for me to clean up his absolute mess that doesn’t even pass the CI.
Call me an asshole I don’t care. It’s been a month and I’m legit worried about the future of the project.20 -
My day:
9 am: crack knuckles, ready to start day
9:01 am: oh, that PR I sent last week hasn't been reviewed yet and I need it in mainline. Better merge latest and get someone to look over it.
9:02 am: now the test suite is broken, better fix that up before getting it reviewed.
1 pm: phew, that was a slog. Now to get on with today actual programming
1:01 pm: "hey buddy, you coming to that tech leads strategy meeting?"
5 pm: Jesus what a meeting. Now maybe I can get a little code written. I'll just fast-forward to latest...
5:01 pm: WHAT DO YOU MEAN THERES A BAD MIGRATION AND EVERYONE SHOULD AVOID USING THE LATEST VERSION WHY DIDN'T YOU REVERT THAT SHIT DO I NEED TO COME OVER THERE AND RESTRICT YOUR STUPID WINDPIPE UNTIL YOU UNDERSTAND GIT *RAGE TABLEFLIP*2 -
Sent my changes before everybody for code review, got git blocked because today was demo day, and ... And asshole guy merged his own PR without code review. That conflicted with my PR. I am going to start posting the shennanigans of asshole guy from now on, just to have a record of his stupidity.10
-
Sometimes I like to look at my PR and think "Damn, that's some beautiful code, I can't wait for someone to review it".
Then the review comes and see a bunch of requested changes. =/5 -
What the FUCK is the point of submitting a PR, if you're going to approve my code, without looking at it, and then LEAVE ME to further refactoring.
I don't mind the refactoring. At. All.
What I DO mind, is being told "yerp, looks good" and then standing aside as I break everything.
TeAmWoRk5 -
The CTO has admin on the git repo and while we all have to have 2 other people review our pull requests. This guy will just go make a pr and merge it without review. It's not like its perfect code either. I will be going behind him and finding weird shit that he did days later and then go check the git blame. Yup its another one of his had to push it right now without review moments.2
-
"can you please approve my PR?" yes, sure I'm happy to drop the context I built in my head, to pick up your totally different context, review your code and then rebuild my context.
I get an automated alert on slack whenever I'm requested a review on git, can't you fucking wait 20-40 mins when I'm out of the zone? Ffs.3 -
A custom script that makes a Jira ticket, assigns it to me, marks it as in progress, check out a git branch, set the commit title and the Jira title to my command line argument…. Push, open a PR, and fuck it, merge that shit too.
I checked all the corporate boxes and you got the typo fixed. -
PR used to mean public relations to me few months back. Now it just means pull requests to me.
The fuck happened. Anyone says we need to improve our PR, I'm like how do you improve a pull request and I end up face palming -
We have pretty fast and lean dev process between QA/Design/Devs.
But sometimes, it's going to shit ;p
QA :
An option "ROLE" is missing for grouping in that table.
So 5 min to create ticket, assign someone from design on it
Design : Yeah, this is true. We missed that option in our design.
Proceds to modift figma by adding an option "Role" to a drop down.
Reasigned to Junior dev.
Junior dev : I have no clue how grouping works with graphql.
So at least 30 min.
Reasigned to me.
Me after 1 min of looking at it : PR chhanges on screen shot :
Facepalm... Everyhtibng was already in place, someone forgot to add id AND name, not just name.
Git blame => Or never mind... it was me.. -
Me: Ok I've updated the docs, I'll open a PR with the changes
Maintainer: Looks great! Can you remove the changes to the package-lock.json? (I assume it got updated when you ran npm install to start the webserver)
Me: Ok sure, I'll update it soon
And this is where the troubles begin. The file was commited 2 commits ago, so I have to roll back to then. However, the remote repository has been updated since then, so I git fetch to keep up to date.
This makes the rollback a hell of a lot harder, so I run git log to see the history. I try a reset, but I went back to the wrong commit, and now a shit ton of files are out of sync.
I frantically google 'reset a git reset', and come across the reflog command. Running that fucks things up even worse, and now so much shit is out of sync that even git seems confused.
I try to fix the mess I've created, and so I git pull from my forked repo to get myself back to where I was. Git starts screaming at me about out of sync files, so I try to find a way to overwrite local changes from the origin.
And by this point, the only way to describe what the local repo looks like is a dumpster fire clusterfuck that was involved in a train wreck
I resolved the mess by just deleting the local copy and git cloning again from my fork.
I gotta learn how to use Git better5 -
/me doing the 23rd revision of a PR because my colleague reviewing it comments on every imaginable way his opinion of code standards differ from mine:
git commit -m "." -
So today my colleague is installing new dependency to our react native project and do something cool with it.
Him: I already push it in new branch and make a pr, would you review and merge it to master.
Me: ok let me try first.
.
.
Me: it is not working, i get this error.
Him: try change these xxx in xcode.
Me: ok, wait.
.
.
Me: now I get this error
Him: hmm... Try 'react-native link xxxx'
Me: ok
.
.
Me: I get same error like first error.
Him: now try 'react-native unlink xxxx'
Me: hmm... Wait.
.
.
Me: I still get same error, what's wrong?
Him: I don't know, it's working in my mechine .
*Me 'git reset - - hard' and try to build again.
**After building
Me: hey it's working after I git reset lol.
Him: nice
Me: let me clone it and try 1 more time.
*after cloning and building
.
.
Me: I still get same error like 1st error hahaha.
Him: so try to 'react-native link xxx' again.
Me: OKkK
.
.
Me: still get same error
Him: try git reset and build again
Me: hmm
.
.
*after git reset and build again
Me: I still get same error. I think the correct steps is :
1. Clone
2. Do something in xcode
3. React native link
4. React native unlink
5. Git reset - - hard
6. Build
I can't stop laughing 😂🤣😂🤣🤣😂🤣😂 -
is it necessary to have cherry picking a part of git branching/release process?
we have 3 branches : develop, release and master.
currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.
so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :
1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.
2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x
3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release
4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.
so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.
for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.
what do you folks suggest?9 -
!rant
27 days ago I asked here for advice on how to mentor software engineer student that was terrible at coding.
So, we are in the middle of the mentoring, my approach is for her to get used to normal engineering tools, in this occasion she is learning Git and "kanban" (basically we are using Clubhouse for this one) and Github PR submission and approval (I'm the one who approves them, naturally) by doing.
With git, things are hard because we cannot share a terminal session (via upterm) due to her using Windows on her laptop (WSL is an option for using upterm but her internet is so damn slow doing the configuration takes way too long), otherwise teaching her use git would be smoother than it is currently, with the other tools she is gaining a good grasp of them, it pleases me that the bottleneck is with Git itself.
She is working on a hangman game with Python, nothing fancy just the terminal. I made the stories with the requirements in Clubhouse for her to work on each as a unit removing some "thought process" of reading requirements and implementing solutions (at Uni it seems the professor writes a document of several pages detailing the background of the project and the requirements, I can see how it can become confusing for some students like her).
She will start Uni again this August 10th, there is a chance that our first "session" at this will end by then, my fear is that she forgets how to use the tools she learned, so I need to find a way to encourage her to keep using them somehow.3 -
1. Teach DS and Algos. Not basics but advanced data structures and the ones that are recently published.
2. DBMS should show core underlying concepts of how queries are executed. Also, what data structures are used in new tech.
3. Teach linkers, compliers and things like JIT. Parsers and how languages have implemented X features.
4. Focus on concept instead of languages. My school has a grad course for R and Java. (I can get that thing from YouTube !!)
5. Focus a little on software engineering design pattern.
6. It's a crime to let a developer graduate if he doesn't know GIT or any version control. Plus, give extra credits for students contributing to open source. Tell them if they submit a PR you get good grades. If that PR gets merged bonus (straight A may be ?)
7. Teach some design pattern and how industry write code. I am taking up a talk at school to explain SOLID design pattern.
Mostly make them build software!
Make them write code!
Make them automate their homeworks!
Make them an educated and employable student.!1 -
Question about git: What do you do when you have a massive pull request? This guy I work with made a PR with 13k files out of which 11-12k is basically HTML's that should have been added as an initial commit, and remaining ones are actual files that we worked on. Should I ask him to somehow split his work in two parts?5
-
Sometimes I genuinely wonder what the thought process of some people is...
git checks out feature-X branch
git creates new branch off of it to work on something that has absolutely nothing to do with feature X
then opens a PR back into feature-X
Me: this has nothing to do with feature X.. i think you meant to branch off of develop and PR back into develop, no?
Them: no it was intentional .. feature-X will eventually end up on develop so I thought we'd get both features on develop.
I'm not even mad and this isn't a rant, I'm just really confused 🙂4 -
Had a branch that I was ready to push to a remote and open a PR tp this big open source project.
I was making a git pull from their master in order to not have merge conflicts on remote... and then I see that their master branch already had the feature that I was trying to implement, merged 10 days ago.
A lot of work... for nothing.
Because I had to wait on some old ass company policy process bs on open source software to give me permission to push to a codebase we're using in their internal product.
Well in today's meeting I made a reference to this... they still insisted on intellecxual preperty bs. Im questioning their ability to think.
Im pushing fixes and enhancements to that without permission, idgaf4 -
I've taken to only allowing PRs on my code if test coverage only deviates negatively within 1%
You can almost hear the tumbleweed.
But that hasn't been merged in yet -
Question about managing git branches.
For releases, we branch develop (the main branch) into a release.version branch in which we bump the version and do any last minute bug fixes for issues found in testing.
After the release we need it back into the main branch as well as master.
But also we keep the branch as well in case we need it such as for a hotfix release.
Is keeping it right though?
General issue on my team I feel is nobody deletes their feature branches after they are done and merged into the main branch. I think there is a feature in most Repos where it can auto delete these branches when a PR is merged.
And well branches themselves (at least the HEAD) are sort of just bookmarks. All commits can be accessed by their hash and basically is a full snapshot of all the commits that upto that point that it was based off of?
So you could just tag the last commit in the release branch with release.version and delete the branch itself? And that I think is the correct, normal way?
Not sure how to explain this to my boss or team as they aren't big on technical details...9 -
Why is it that when you try to run a project and have ample dev but none of them wants to raise a PR because they are too scared to get feedback.
Oh you have done that can I see it on our pipeline or Git.....
Blank Face No.
Why?!
Because it won't run on pipeline.
Really3 -
Is git a history of what happend or a list intentional changes?
Had this discussion with my boss. He said i shouldn't rebase my feature branch because it is too much hassle (I did some squashing and fixups). I should just commit on top and merge master into my branch.
What is your git philosophy?
Do you "own" a feature branch until you create the PR?6 -
I have a git feature branch with my commits but also have merged the changes from the main branch to resolve merge conflicts before PR.
But now need to create a special release with just my changes.
So I think have to cherry pick all my commits on my branch some the last Release. How can I do that?
Develop (others) + Feature => Develop
Want to create new branch
Last Release + Feature (but only my commits since last Release)3 -
Ugh. Been working on a huge React component that's now dependant on another co-workers PR, and had this one open for like a week. Go to merge and one of the fucking useless reviewers decides that *now* is the best time to flag everything wrong with my code!
I get it, it's good feedback, but uh... Could you not have done this a FUCKING WEEK AGO instead of RIGHT BEFORE I GO TO MERGE?!
Prick.2 -
Want to open all the files changed in a PR?
> code $(git diff master --name-only)
#git #vscode #vscodehacks4 -
"Worst drunk coding experience?"
My alcohol tolerance is very low. So, every stupid attempt of my coding in such a state is the worst experience.
There's this pulsing feeling in my skull every 10 seconds blocking my attention.
And there's an increased chance of mistyping commands.
One time, for some reason, I kept "pulling" the git commits when I actually wanted to "push" them. I spent a lot of time finding out why the f*<k GitLab is not showing my new commits in my PR before realizing my sheer stupidity.
And it takes me only one 3.5dl can of low alcohol content (like 3% abv) drink to relive these experiences. WTF. -
Pull >>>> Rebase
The advantages of rebase (clean git history) are minimal but the risks are massive (rebasing in the wrong direction, rebasing after raising a PR, rebasing a public branch)4 -
I just commented a test so the PR passes and the feature reaches next release; I can't fix it (Damn react testing library tests)
but after that, the linter failed for the same PR, so I just fixed it and did a git push -f
I guess once you cross the line you cannot come back
feel my pain1 -
Learn git. Contribute to open source projects - you may learn more from code review on a single PR than from a whole tutorial. Ask questions constantly. Learn more git. Look for the cleanest solution to a problem. Write code that is easy to improve, easy to expand, and easy to debug. Learn even more git. Don't limit yourself to thinking only in terms of OOP, or functional, or procedural, or whatever type of programming you may be comfortable with. Don't be afraid to do some work by hand. Learn git, so that when all comes crashing down and your team crumbles to pieces, when your relationships fail and your friends disappear, when you're down on your luck and there truly is no hope left in life, you can check out of the dangerous world of your current HEAD and return to the home and comfort of your master branch, which you've kept safe, secure, and functional.