this post was submitted on 03 Mar 2024
1032 points (98.0% liked)

Programmer Humor

19817 readers
1399 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 160 points 10 months ago* (last edited 10 months ago) (16 children)

Interviewer: It's git push origin main now. Get out of here!

[–] [email protected] 16 points 10 months ago (1 children)

Just set your default behavior.

[–] [email protected] 19 points 10 months ago (9 children)

I have only ever used simply "git push". I feel like this is a "how to say that you barely know how to use git without saying that you barely know how to use git" moment:-D.

load more comments (9 replies)
load more comments (14 replies)
[–] [email protected] 70 points 10 months ago (3 children)

I once had HR ask if I was familiar with G-I-T ( she spelled it out), for a moment, my only thought was "wtf is G-I-T".

[–] [email protected] 53 points 10 months ago

I might be the dumb one in this one, but HR asked me if I know "design patterns".

"I mean, yes, I know some design patterns. Any specific?"

"No, just if you are familiar with design patterns."

"I mean, there are builder, strategy, sigleton, factory etc. Is the question really not more specific?"

"My paper just asks if the dev is familiar with design patterns."

"Ok. Yes."

[–] [email protected] 18 points 10 months ago (3 children)

One of my first interviews in Canada I was asked what a β€œzed-index” is and was like what? A what now?

load more comments (3 replies)
load more comments (1 replies)
[–] punkwalrus 65 points 10 months ago (10 children)

The thing is that for a majority of cases, this is all one needs to know about git for their job. Knowing git add, git -m commit "Change text", git push, git branch, git checkout , is most of what a lone programmer does on their code.

Where it gets complicated real fast is collaboration on the same branch. Merge conflicts, outdated pulls, "clever shortcuts," hacks done by programmers who "kindof" know git at an advanced level, those who don't understand "least surprise," and those who cut and paste fixes from Stackexchange or ChatGPT. Plus who has admin access to "undo your changes" so all that work you did and pushed is erased and there's no record of it anymore. And egos of programmers who refuse any changes you make for weird esoteric reasons. I had a programmer lead who rejected any and all code with comments "because I like clean code. If it's not in the git log, it's not a comment." And his git comments were frustratingly vague and brief. "Fixed issue with ssl python libs," or "Minor bugfixes."

[–] Ottomateeverything 47 points 10 months ago (1 children)

I had a programmer lead who rejected any and all code with comments "because I like clean code. If it's not in the git log, it's not a comment."

Pretty sure I would quit on the spot. Clearly doesn't understand "clean" code, nor how people are going to interface with code, or git for that matter. Even if you write a book for each commit, that would be so hard to track down relevant info.

[–] mkwt 30 points 10 months ago (4 children)

Yeah, I think that guy only got a superficial understanding of what Uncle Bob was saying.

My policy as a tech lead is this: In an ideal world, you don't need the comment because the names and the flow are good. But when you do need the comments, you usually really need those comments. Anything that's surprising, unusual, or possibly difficult to understand gets comments. Because sometimes the world is not ideal, and we don't have the time or energy to fully express our ideas clearly in code.

My policy on SCM logs is that they should be geared more towards why this commit is going in, not what is being done. And what other tickets, stories, bugs it relates to.

[–] [email protected] 20 points 10 months ago (1 children)

Lead of a small team of scripters here. The "Why. Not What" is defo a good way of encouraging cleaner code.

Had to request changes recently on a PR like this, big function with comments telling me what it was doing. When they resubmitted for review they had broken it down into smaller functions with good variable/function naming. following what was going on was much easier

load more comments (1 replies)
load more comments (3 replies)
[–] [email protected] 18 points 10 months ago (2 children)

β€œFixed issue with ssl python libs,” or β€œMinor bugfixes.”

Red bird going "Hahaha, No!"

In other news, never work more than one person on a branch (that's why we have them). Make a new related issue with its own branch and rebase whenever necessary, and don't even think about touching main or dev with anything but a properly reviewed and approved PR (in case they aren't already protected), or I'll find and report you to the same authority that handles all the failed sudo requests!

Also, companies that disable rebasing are my bane. While you can absolutely do without, i much prefer to have less conflicts, cleaner branches and commits, easier method to pull in new changes from dev, overall better times for the reviewer, and the list goes on. Though, the intern rewriting multiple branches' history which they have no business pushing to is also rather annoying.

load more comments (2 replies)
load more comments (8 replies)
[–] Wilzax 38 points 10 months ago (14 children)

So do you guys pronounce it git or jit

[–] ikidd 43 points 10 months ago (1 children)

Is that what we're going to do tonight, we're gonna fight?

load more comments (1 replies)
[–] [email protected] 20 points 10 months ago (1 children)

I pronounce it the correct way you silly git!

load more comments (1 replies)
[–] [email protected] 14 points 10 months ago (1 children)

Don't start this. Its not like gif. Git is clearly pronounced like git. There is no possible argument you can make otherwise.

load more comments (1 replies)
load more comments (11 replies)
[–] [email protected] 32 points 10 months ago (1 children)
[–] aeharding 40 points 10 months ago* (last edited 10 months ago) (4 children)

git: 'gud' is not a git command. See 'git --help'.

rekt

load more comments (4 replies)
[–] Ohi 31 points 10 months ago

Aye, most of my 10 year career in web dev is pretty much those commands. However, some advanced git concepts are worth diving into. Stuff like git bisect that can narrow down the exact commit that broke your app is an absolute life saver. Knowing how to git cherry-pick is also a git skill professionals should be comfortable doing. Migrating work from one branch to another without merging the entire branch is pretty common.

[–] [email protected] 31 points 10 months ago (5 children)

Once you understand that everything is similar to a tag, like branch names are basically tags that move forward with each commit, that HEAD is a tag that points to your current commit location in history, and what command moves what kind of tag, it becomes easier to understand.

Suddenly having a detached HEAD isn't as scary as you might think. You get a better understanding of fast forward merges vs regular 3-way merge.

Also understanding that each commit is unique and will always remain in the history and can be recovered using special commands. Nothing is lost in git, unless you delete the .git sub-directory.

[–] [email protected] 12 points 10 months ago (4 children)

For folks unaware, the technical git term, here, is a 'ref'. Everything that points to a commit is a ref, whether it's HEAD, the tip of a branch, or a tag. If the git manpage mentions a 'ref' that's what it's talking about.

load more comments (4 replies)
load more comments (4 replies)
[–] [email protected] 30 points 10 months ago (15 children)

If you happen to forget the -m though, you may also need to have mastered exiting vim

load more comments (15 replies)
[–] Anticorp 29 points 10 months ago (7 children)

If you're pushing to master, then you're doing it wrong.

[–] [email protected] 23 points 10 months ago (7 children)

Yeah main has been the defacto default branch name for like half a decade now

[–] TunaCowboy 11 points 10 months ago

git whoosh --hard

load more comments (6 replies)
load more comments (6 replies)
[–] [email protected] 22 points 10 months ago* (last edited 10 months ago)

Average linux user managing his dotfiles.

Yes I'm guilty of that, only thing more I know is creating new branches.

[–] [email protected] 20 points 10 months ago (1 children)

git blame is another good one

load more comments (1 replies)
[–] [email protected] 17 points 10 months ago (1 children)

As someone who knows that they know very little about git, this thread makes me think I'm not alone.

[–] [email protected] 19 points 10 months ago (1 children)

I think advanced git knowledge, like RegEx, is the exception, while the norm is to know the tiny handful of day to day useful bits

[–] [email protected] 10 points 10 months ago (2 children)

How is regex git knowledge? I guess you can use regular expressions with git grep but it's certainly not a git-oriented concept...

[–] [email protected] 17 points 10 months ago (1 children)

what. that's not what they said. they are comparing git knowledge to regex knowledge.

[–] [email protected] 10 points 10 months ago (1 children)

Ah, thanks for the explanation. I too misunderstood the inflection.

load more comments (1 replies)
load more comments (1 replies)
[–] [email protected] 13 points 10 months ago (1 children)

Well, if anyone wants to learn more about Git, I can recommend this: https://ohmygit.org

load more comments (1 replies)
[–] [email protected] 12 points 10 months ago

Every once in a while, you can refresh your memory by reading the man page.

Or if, like me, you use Emacs, Magit exposes everything quite clearly.

[–] [email protected] 12 points 10 months ago (1 children)

I made do with my IDE, even after getting a developer job. Outside shenanigans involving a committed password, and the occasional empty commit to trigger a build job on GitHub without requiring a new review to be approved, I still don't use the commandline a lot.

But it's true, if you managed to commit and push, you are OK. Even the IDE will make fixing most merges simple.

load more comments (1 replies)
[–] go_go_gadget 11 points 10 months ago (1 children)

Woah look at mr. fancy pants with his git push arguments.

load more comments (1 replies)
[–] Marcbmann 10 points 10 months ago

I think HR is just ill equipped for technical interviews, but they try to conduct them regardless.

Was denied a position because HR felt my experience "lacked depth" which I still can't understand 3 years later.

Did the same role at a larger company. Had more responsibility than they were giving me. Developed my own tools for job automation. Grew their business from nothing to half a mil a month. Experienced all stages of growth and realized massive success.

After that interview I kept getting technical interviews and getting passed on because I was too senior for the position

[–] [email protected] 10 points 10 months ago (1 children)

Learn to use git bisect. If you have unit tests, which of course you should, it can save you so much time finding weird breakages.

[–] [email protected] 10 points 10 months ago

With automated CI, I've had very few times where bisect is useful. Either the bug was introduced 1-2 commits ago, or it's always been there and the exact commit is irrelevant to the solution, since you just fix it forward.

load more comments
view more: next β€Ί