I can git... But not CLI. Idk why, but those commands ain't staying in my brain.
this post was submitted on 03 Mar 2024
1100 points (97.7% liked)
Programmer Humor
20735 readers
632 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
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
Just need more terminal time, it comes with experience.
You should run Arch, btw
load more comments
(1 replies)
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.
load more comments
(9 replies)
One of my system engineers started using TFS a few weeks ago. All he knows how to do is click Sync Changes in vscode and call me if there's a problem.
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."
If it’s not in the git log, it’s not a comment.”
This is so incredibly dumb, though I’m sure I don’t have to tell you this. That comment will be buried in the git log if anyone ever fixes a typo on that line.
“Fixed issue with ssl python libs,” or “Minor bugfixes.”
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)
Why does
git rebase
work sometimes?
Yeah git can get quite complicated when there ate lots of people working on the same things.
It's not git that's complicated. The work is complicated. git is just one of the tools that programmers use to manage the complexity.
I also think that some people get too hung up on having a "clean" history, and trying to "fix" the history after it has already occurred. I usually have enough problems to worry about in the present, without also trying to worry about the past.
I like to rebase on my feature branches before the PR because it’s a gift to my future self that resolves all the conflicts (if any) before my work goes in. I just find trying to figure out how those conflicts got resolved when there are a bunch of merges in more difficult if there’s a problem later. It’s easier to understand for me. YMMV, this does not work for everyone. Etc etc.
load more comments
(3 replies)
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.
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.
But when you do need the comments, you usually really need those comments.
It’s nice to see you sharing my experience. My code is either uncommented or very severely commented with comment-to-code ratios of 10:1 or more. I hate the files that are soo green… :(
We solve that problem using naming conventions. Branch names must start with the issue key (we use Jira). You don't do anything in that branch that's not part of that issue. If you do, you must prefix the commit message with the issue key that it goes with. The commit itself identifies what changed. The Jira issue provides all the backstory and links to any supporting materials (design docs, support tickets, etc). I have to do a lot of git archeology in my role, and this scheme regularly allows me to figure out why a code change was made years ago without ever talking to anyone.
load more comments
(1 replies)
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
(1 replies)
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)
Interviewer: It's git push origin main now. Get out of here!
Fuck those that use main. If you're working on a library fork that has main and a project that has master you're bound to invert the two.
"What do you mean I can't checkout main? Oh right, here it's master..."
For once that we had a standard, it had to be ruined.
load more comments
(13 replies)
Just set your default behavior.
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.
Hold Up
The first time you manually push like that, you can add the -u flag (git push -u origin master) to push and set the branch's default upstream. Afterwards, a plain git push while that branch is checked out will push the branch to that default upstream. This is per-branch, so you can have a main branch that pulls from one repository and a patch branch that pulls and pushes to a different repository.
load more comments
(2 replies)
You can default git to using your current branch and a specific upstream so you don't have to put anything after git push
Thanks didn't know that
Has git never told you that you should use git push -u origin <branch> when you push a new branch for the first time?
load more comments
(2 replies)
Average linux user managing his dotfiles.
Yes I'm guilty of that, only thing more I know is creating new branches.