Have they considered writing code that does build? (I’m joking to be clear)
That’s worse than /s
By far yes. It hurt to write.
Now that we’ve moved away from reddit can we just bring back emojis already? I know. I KNOW. They’re hated for some silly reason but I’d rather see 😏 than jk or /s in any form ever.
I’m not against using emojis, I just haven’t used them enough to be familiar with them.
I’m honestly amazed that the no emoji culture on Reddit persisted even after it became super mainstream. But agreed, I actually like emoji for adding emotion/intent indicators to text. I use them all the time in personal conversations and work Slack, but never ever on Reddit for whatever reason haha.
I used emojis on Reddit all the time and never got any flak for it.
Yes, 👍👍👍👍👍👍👊 It’s only when someone👦👧🧔♀️👱👶👨 uses them like this that we hate💔💔💔💔💔💔💔💔💔💔them😡😡😡😡😡😡😡
They’ve been a little less militant about it over the last couple of years. Probably because newer/younger users have been rolling in that don’t have the hate for it lol
Travis used to be brutal about this. Email headlines that were like “Still failing…”, one piled up after another when you were trying to tweak the CI process.
I’m sorry dad, I wasn’t trying to have a miscarriage!
I feel attacked right now.
And you know you have to hit that rebuild button at least once.
I still feel that building an executible file that builds the code is easier than git actions 😰
How to minimize API usage: burn the user.
These companies getting creative, you guys.
i cannot stand git. nobody is physically capable of explaining how it works and how to actually use day to day. the vocab seems intentionally chosen to be confusing – ‘push’ and ‘pull’ are too similar and vague [edit my uni taught the tree concept first, and explained in such a way that i could never remember if the server would push an update down to me or i would push an update up]
Is this a joke or are you for real?
Pushing/Pulling might seem simple to you, Odium, but not everyone is so passionate or invested.
I mean sure, when I first used git it was a bit confusing as I have never used a similar platform but after visiting a few times you can easily get the hang of it. But that post was super exaggerated claiming “no one” can understand it as if its rocket science, so can’t tell if its a troll or just a clueless dude who gave up after trying once.
My comment is actually an unrelated in-joke forcibly coerced into the shape of a discussion about
git. It’s a whole fictional magical universe thing with a lore wiki and stuff:- “Odium”/“passion”: https://coppermind.net/wiki/Odium
- “invested”: https://coppermind.net/wiki/Investiture
- “Pushing”: https://coppermind.net/wiki/Steel#Allomantic_Use
- “Pulling”: https://coppermind.net/wiki/Iron#Allomantic_Use
bro what? literally most devs use it day to day and plenty of people know how it works. push and pull are literally opposites, and used to push and pull from a remote, how is it too similar and vague?
Some people know how it works, but no one takes the time to explain in plain language exactly how.
No surprise, given that it’s made for and by software programmers.
But like know how it works for using it or know how it works…
Those are very different statements, and the latter is really unimportant
To be fair, I have seen many people confused by git (in fact, there is a relevant xkcd). So for you and anyone else that could use some help:
Git is just a version tracker. It is basically like naming a files “project_1”, “project_2”, “project_final”, etc. It just does the hard work of remembering history for you, and only shows you the current version.
The commands are somewhat oddly named, but are fairly intuitive:
git add- adds some of the current changes to the tracker (“stages” them).git commit- commits (i.e. saves) the currently staged changes to a new point in your history (a ‘commit’)git checkout- check out, as in take a look at, another branchAnd you shouldn’t think about pushing and pulling as a tree; think about it as an action you take. You either pull changes in from the server or you push them up to the server.
For more complex situations, you will need to use more complex functionality. Git is built to help manage changes when working on a team, so it has the concept of creating new branches of history - like an alternate timeline - so that each individual can work on their code as if they were working alone. When they are ready to send their changes to the main (or master) version, they can merge the changes in. In the event that you want to change history, there is git amend and git rebase.
The normal work flow goes like this:
git checkout -b new-feature: check out a new brach, based on the one you are on now- make some changes
git add file.txt (or -A for all): add your changes to trackinggit commit: save the changes to a new commit (a new point in history). This will try to open an editor so you can write a short message explaining the changes; you can use-m "message"to specify a message from the command line if you prefer.- repeat until you are done working
git push: send your changes to the remote server (add--set-upstream origin new-featureif this is the first time for this branch)- open a pull request or something similar so someone else on the team can review and approve your code
- merge the pull request in
If your changes fall behind the main branch, you will need to update your branch before merging it in. First, checkout the main branch and pull the new changes. Then, checkout your branch and add the changes from main. There are two ways of doing this:
git merge main- merge the changes you are missing from main, creating a new point in history for the combined changesgit rebase main- change history so that it is as if your changes started from where main is now - change the base of your branch to be the current state of main.If there are conflicts, stay calm and take a look at your files. You should see something like this (from here:
here is some content not affected by the conflict <<<<<<< main this is conflicted text from main ======= this is conflicted text from feature branch >>>>>>> feature branchYou need to edit the file to decide which of main’s code and which of your branch’s code to use. Once you are done, run:
git commit: if you are doing the merge methodgit rebase --continue: if you are rebasing. A rebase resolves conflicts one commit at a time, so you might be editing code from previous commits, and you might need to repeat this process for the rest of your commits until you get back up to now.Another tip: if git complains about uncommited changes, or if you just want to save all of your changes somewhere and go back to a clean slate, you can use
git stash. This will create a local stash of your current changes, and allow you to get them back later withgit stash applyorgit stash pop.And you aren’t expected to remember it all. That’s what
man git, Google, and websites like git.wtf are for. Or, you can call that one friend who understands it, and ask them for help ;)nice
please say sike right now
They’re not committed to the joke.
Push and pull are purposefully similar because they’re doing the same actions in opposite directions
Damn this cryptic bullshit! / 😉
Just memorize these commands and don’t question it!
Do you push things towards you or away from you? Do you pull things away from you or towards you, ya donut?
