this post was submitted on 09 Nov 2023
1262 points (98.2% liked)

Programmer Humor

32361 readers
301 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] DarkwinDuck@feddit.de 89 points 1 year ago (2 children)

So you're going to git gud?

[–] lseif@sopuli.xyz 71 points 1 year ago (1 children)

if u ever get a tricky merge conflict, just git push --force. this automatically works out the right code to keep (your own)

[–] erogenouswarzone@lemmy.ml 15 points 1 year ago (1 children)

Also, a way to never have to work again!

[–] Nahdahar@lemmy.world 8 points 1 year ago

Except if you're an employer in a very small company.

Source: my boss did this at the first company I worked at.

[–] TeaHands@lemmy.world 65 points 1 year ago

Highly recommend bookmarking https://ohshitgit.com, it'll steer you right 👍

[–] ArbitraryValue@sh.itjust.works 54 points 1 year ago (1 children)
  1. git pull
  2. git reset --hard HEAD
  3. try not to cry
  4. cry a lot
[–] CalcProgrammer1@lemmy.ml 17 points 1 year ago (1 children)

git reflog, you can get your old commits back

[–] ArbitraryValue@sh.itjust.works 15 points 1 year ago (1 children)

But I want to pretend none of this ever happened.

[–] winterayars@sh.itjust.works 6 points 11 months ago
git can we just pretend the last 30 minutes never happened

I feel like that would get more use than people want to admit.

[–] cupcakezealot@lemmy.blahaj.zone 36 points 1 year ago (2 children)

lemme rebase the main branch onto my branch.

two minutes later

1 merge conflict of 57 [abort] [continue]

[–] affiliate@lemmy.world 13 points 1 year ago (1 children)

this is easily fixed by copy pasting the files into a new directory and never opening git again out of fear

[–] caseyweederman@lemmy.ca 12 points 1 year ago

Project managers hate this one weird trick!

[–] kamen@lemmy.world 7 points 1 year ago

One key thing that can help you wrap your head around rebasing is that branches get switched while you're doing it; so, say you're on branch feature and do git rebase master, for any merge conflict, whatever's marked "current" will be on master and what's "incoming" is from feature.

There's also git rerere that should in theory remember a resolution you do between two branches and reuse it every time after the first; I've rarely used it in practice; it would happen for long lived branches that don't get merged.

[–] stilgar@infosec.pub 28 points 1 year ago

Pro tip: If your code gets flogged by git, you can always get revenge with git reflog 😉

[–] lily33@lemm.ee 25 points 1 year ago (8 children)

Learning git is very easy. For example, to do it on Debain, one simply needs to run, sudo apt install lazygit

[–] Kata1yst@kbin.social 23 points 1 year ago

LazyGit may actually be black magic from Satan to tempt programmers into sin. And to that I say: 'where is a goat I can sacrifice to my dark lord?'

load more comments (7 replies)
[–] roastpotatothief@lemmy.ml 21 points 1 year ago* (last edited 1 year ago) (2 children)

Git is a great invention but it has a few design flaws. There are too many ways to confuse it or break it, using commands that look correct, or just forgetting something. I ended up writing simple wrapper script codebase to fix it. Since then no problems.

[–] oce@jlai.lu 17 points 1 year ago (4 children)

It was conceived for experts so the new user experience is shit and the UI is not intuitive. But it has become such a widespread standard that it is very hard to completely overhaul the UI.

[–] sheogorath@lemmy.world 9 points 1 year ago (1 children)

TBH compared to the old versioning system people used to use like SVN and Mercurial. Git is a godsend. Just taking your time in learning and not using a GUI client works wonders in learning how it works. Especially when all the GUI clients are basically a collection of commands being executed so if you fuck things up on CLI you know what happened vs using GUI.

load more comments (1 replies)
load more comments (3 replies)
load more comments (1 replies)
[–] Andrew15_5@mander.xyz 20 points 1 year ago (2 children)
load more comments (2 replies)
[–] fer0n@lemm.ee 17 points 1 year ago* (last edited 1 year ago) (1 children)

This has been the best git tutorial I’ve come across so far. Nicely interactive and gamified. https://learngitbranching.js.org/

load more comments (1 replies)
[–] AMillionNames@sh.itjust.works 16 points 1 year ago
[–] Skullgrid@lemmy.world 12 points 1 year ago

...not by choice, because if I don't I'll lose my job

[–] doppelgangmember@lemmy.world 12 points 1 year ago* (last edited 1 year ago)

Just rebase your life already

[–] erogenouswarzone@lemmy.ml 12 points 1 year ago* (last edited 1 year ago) (4 children)

Great meme, and I'm sure op knows this, but for anyone else who is curious...

007 in theory means:

  • 00: you have already committed your code to your local code base
  • 7: When you try to merge your code with everyone else's there are 7 files that others have worked on since you last refreshed your local code base.

To resolve this, you need to go file by file and compare your changes with the changes on the remote code. You need to keep the changes others have made and incorporate your own.

You can use git diff file_name to see the differences.

If you have made small changes, it's easier to pull and force an overwrite of your local code and make changes again.

However multiple people working on the same files is usually a sign of organizational issues with management. Ie, typically you don't want multiple people working on the same files at the same time, to avoid stuff like this.

If you're not sure, ask someone that knows what they're doing before you follow any advice on Lemmy.

load more comments (4 replies)
[–] yoz@aussie.zone 11 points 1 year ago (6 children)
[–] twei@feddit.de 36 points 1 year ago (1 children)
load more comments (1 replies)
[–] NaoPb@eviltoast.org 13 points 1 year ago

It's what americans from a rural area say when they want you to go away.

[–] alcoholicorn@hexbear.net 5 points 1 year ago

It's the thing you use to create a local copy of the main code base, and then merge your changes back in.

OP hasn't done anything, and there's 7 conflicts between his code and main. Presumably because someone else merged their changes in the time between when OP pulled his local copy and tried to push his (non-existent) changes.

[–] EpicFailGuy@lemmy.world 5 points 1 year ago (1 children)

is what people who don't know vim and rsync have to use to mimic 1% of our power

load more comments (1 replies)
[–] UNWILLING_PARTICIPANT@sh.itjust.works 4 points 11 months ago (1 children)

A very complicated way to do

My project
My project (1)
My project WORKING
My project (2)
My project (2) (1)
load more comments (1 replies)
load more comments (1 replies)
[–] noddy@beehaw.org 10 points 1 year ago (1 children)

I prefer rebasing on destination branch before merging. When merging you get all the conflicts at the same time. When rebasing you can address conflicts from one commit at a time. Untangling multiple small knots is easier than one huge spaghetti. Also commit history will be much cleaner.

load more comments (1 replies)
[–] shiveyarbles@beehaw.org 8 points 1 year ago

When we switched from svn, we had to figure out git with submodules.. that was fun

[–] Haus@kbin.social 6 points 1 year ago (3 children)

sccs, rcs, cvs... after that it's a blur of new systems every year or two

[–] kautau@lemmy.world 13 points 1 year ago* (last edited 1 year ago) (1 children)

sccs

1973

rcs

1982

git

2005

How long are your years?

load more comments (1 replies)
load more comments (2 replies)
[–] Netrunner@programming.dev 5 points 1 year ago (6 children)

If you can't use git I don't see how you're gonna do with other things. It's dead simple.

[–] jack@monero.town 28 points 1 year ago (2 children)

Solving merge conflicts or rebasing is not simple

[–] lightnegative@lemmy.world 13 points 1 year ago (1 children)

Do it enough times and it stops being scary.

Using a tool like VSCode to perform the actual merges on individual files also helps because it shows what "yours" and "theirs" changes are from a user perspective, not a git perspective

load more comments (1 replies)
load more comments (1 replies)
[–] oce@jlai.lu 13 points 1 year ago* (last edited 1 year ago) (1 children)

If it was dead simple you wouldn't need to learn 10 new concepts and google commands regularly even after using it for a couple of years. You probably forgot how you struggled at first. I have taught it multiple times and I see how beginners struggle.

load more comments (1 replies)
[–] space_comrade@hexbear.net 13 points 1 year ago* (last edited 1 year ago)

It's not THAT complicated but I wouldn't call it dead simple. When you understand how git works internally yeah it's pretty simple but people usually start with the idea that it's a tool to put your code on a server to synchronize with other people and only later learn that you have both a local and a remote (or multiple remote) tree and how the tree really works.

I think the problem is most git 101 tutorials teach it wrong, IMO the best git tutorial is this: https://wildlyinaccurate.com/a-hackers-guide-to-git/

Unfortunately it's pretty dense so it's gonna scare off a lot of newbies.

[–] sajran@lemmy.ml 5 points 1 year ago

I would actually say it's VERY complicated but in daily work you probably need like 5 commands and those aren't hard at all.

load more comments (2 replies)
[–] brainw0rms@hexbear.net 5 points 1 year ago (1 children)

or for people who don't have a week to dedicate to learning utterly deranged nonsense, just use sublime merge and never look back. comfy

[–] comrade_pibb@hexbear.net 14 points 1 year ago

sublime merge is pretty great, but having a working familiarity with the underlying tool is invaluable when shit inevitably goes sideways while collaborating

[–] ensignrick@startrek.website 4 points 1 year ago

So many orphaned branches... Poor things.

load more comments
view more: next ›