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

Programmer Humor

19813 readers
283 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 9 months ago* (last edited 9 months ago) (16 children)

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

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

Just set your default behavior.

[–] [email protected] 19 points 9 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 9 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 9 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 9 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 9 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 9 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 9 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 9 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 9 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 9 months ago (14 children)

So do you guys pronounce it git or jit

[–] ikidd 43 points 9 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 9 months ago (1 children)

I pronounce it the correct way you silly git!

load more comments (1 replies)
[–] [email protected] 14 points 9 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 9 months ago (1 children)
[–] aeharding 40 points 9 months ago* (last edited 9 months ago) (4 children)

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

rekt

load more comments (4 replies)
[–] Ohi 31 points 9 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 9 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 9 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 9 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 9 months ago (7 children)

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

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

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

[–] TunaCowboy 11 points 9 months ago

git whoosh --hard

load more comments (6 replies)
load more comments (6 replies)
[–] [email protected] 22 points 9 months ago* (last edited 9 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 9 months ago (1 children)

git blame is another good one

load more comments (1 replies)
[–] [email protected] 17 points 9 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 9 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 9 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 9 months ago (1 children)

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

[–] [email protected] 10 points 9 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 9 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 9 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 9 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 9 months ago (1 children)

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

load more comments (1 replies)
[–] Marcbmann 10 points 9 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 9 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 9 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 β€Ί