If you happen to forget the -m though, you may also need to have mastered exiting vim
What developer uses Linux in professional work? Maybe for on the side stuff but I haven’t seen any corporate Linux machines.
Macs are basically BSD, and Windows has WSL.
But Mac or WSL are not Linux.
Everywhere I’ve worked, you have a Windows/Mac for emails, and then either use WSL, develop on console in Mac since it’s Linux, or most commonly have a dedicated Linux box or workstation.
I’m starting to see people using VSCode more these days though.
I thought Mac was unix which is similar but different from Linux?
I think someone else said what it actually is in another comment. It’s functionally identical 90℅ of the time for me anyway,and I use CLI and vim on it.
They’re both UNIX-like, i.e. they both implement the POSIX specification and are therefore in many ways compatible.
But yeah, modern macOS is more directly derived from the original UNIX operating system.
Linux was instead implemented from scratch to be compatible with UNIX.
Hello, I use a linux machine for dev work and all the servers and containers I touch are linux, all managed through gitlab CI/CD.
git scm is my daily driver and I use it for not taking and documentation as well as active python development.
The entire IT ecosystem is built around Linux, because it’s so prevalent in servers, containers, budget hardware and the open-source community.
Yes, many companies don’t understand that and expect their devs to be productive on Windows. But in my experience, that’s an uphill battle.
In my company, we get very little IT support, if we decide to order a Linux laptop and we still have significantly less trouble with getting things set up to start coding.
Not to mention the productivity boost from having all the relevant technologies natively available + being able to script whatever you want.
Me as an Emacs user, who omits -m on purpose to practice quitting vi in case I really need it
you’re an emacs user who has vi set up as the default editor on your system?
(You can change it altering the $EDITOR env var)
I only use $EDITOR to launch vi from git. Emacs runs as a single process and is always open.
The day I configured
gitto use Geany for commit messages with a separate config specifically tuned for this, it improved my life by 300%~$ cat ~/bin/gitedit #!/bin/sh exec /usr/bin/geany -i -s -t -c ~/.config/gitgeany $@Then in git config:
git config --global core.editor "gitedit"
As someone who knows that they know very little about git, this thread makes me think I’m not alone.
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
How is regex git knowledge? I guess you can use regular expressions with
git grepbut it’s certainly not a git-oriented concept…I don’t even know how to respond to this considering it has nothing to do with what I said…
There are at least two ways to parse your statement, and they interpreted it differently from your intention.
I guess, if you ignore the comma…
Could’ve written like this to avoid the ambiguity: “I think advanced git knowledge, just like RegEx, …”
Rereading it, I now understand what you meant. I interpreted the “like regex” as an example of advanced git knowledge. I’m not sure the comma helps make it unambiguous though.
Yeah, reading it again and I can see that interpretation…
This is why you shouldn’t rely on yourself alone for proofreading your writing, I probably could have read that a hundred times and not seen another way to read it without someone else pointing it out
what. that’s not what they said. they are comparing git knowledge to regex knowledge.
Ah, thanks for the explanation. I too misunderstood the inflection.
I can git… But not CLI. Idk why, but those commands ain’t staying in my brain.
The commands are notoriously poorly named. The underlying tech is cool and sensible, the text interface isn’t.
Just need more terminal time, it comes with experience.
You should run Arch, btw
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 bisectthat can narrow down the exact commit that broke your app is an absolute life saver. Knowing how togit cherry-pickis also a git skill professionals should be comfortable doing. Migrating work from one branch to another without merging the entire branch is pretty common.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.
Seeing Peter Griffin labelled as “HR”, I automatically pronounce the R as “Ah” in my head.
git blame is another good one
Yes, I think we all like to blame git
Average linux user managinh his dotfiles.
Yes I’m guilty of that, only thing more I know is creating new branches.
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
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.
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.
Right. I just wanted to keep it as simple as possible.
Honestly I’ve come to realise that being precise is the simplest in the long run
People get overloaded with words. You have to focus on one concept at a time. Let them ask for others.
Oh, no worries, just figured I’d add that extra little bit of detail as it’s a useful hook into a lot of other git concepts.
Orphaned commits can get garbage collected at some point, though.
Oh fuck. I didn’t think of that. Than you for reminding me.
Edit: Ah but you can only run this in your local repo. If you happen to push anything, you might not be able to run it on the remote. Many DevOps platforms won’t allow it.
Oh yeah, and anybody else who had fetched in those commits may still have them as well. It’s hard for something to be gone-gone, but it may be annoyingly-hard-to-recover-gone.
If you’re pushing to
master, then you’re doing it wrong.Yeah
mainhas been the defacto default branch name for like half a decade nowWait. It’s that long?
Felt like we joke about the announcement 2 years ago. Time fly lol
Imma be honest I pulled that estimate out of my ass lol, but I feel like it was pre-pandemic? which would put it at at least 4 years ago and so holy shit I’m gonna go cry in a corner because it’s been 4 years since the start of the pandemic
git whoosh --hardIsn’t this only the case in github? All my repos are based from master, and I would assume that’s because I init on the command line and push up to the remote?
GitLab also changed a few years back. We host our own, so got the update later than people using the service … it was a bit of an argument at first since everyone wanted to stick with the familiar, but laziness won out. Unfortunately, it’s not really justifiable to go back and change legacy projects, so now it’s inconsistent
If you don’t have any scripts that rely on branch name it should be pretty trivial actually. But I wouldn’t be shocked if you had a few dozen scripts that nobody has looked at in the last century lol
Why? I almost always have master/dev/stable.
You should not be pushing into your main/master/whatever branch.
All the main/master replies completely miss the point, further emphasizing sirsirsalot’s statement.
I think I’ll keep doing it. It’s worked fine for the past decade 🤷
Different workflows.
git send-email
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.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.
All these comments and no one is going to point out that this is invalid?
The git stage and git commit don’t have any terminator, so it’s all one “command” and will fail. Then there’s a single & between git commit and git push, so it would run in parallel, so it would also fail.
Also, don’t
git stage .people. Or at least do agit statusbefore to make sure you didn’t stagefile-with-all-the-production-secretsThe comma and ampersand are plain English, not one big command
Pffft… all of my api keys are open source. Having more eyes on them will make them more secure!
git gud
git: 'gud' is not a git command. See 'git --help'.rekt
They should add that command, just to screw up this joke
zsh: command not found: rektgit help
git rekt
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.”
Your lead sounds like someone who thinks you’re charged per line of code you commit.
“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.
I hate when helpful features like hook scripts aren’t enabled. Someone forgot to run a script before pushing their changes even though the readme clearly says to format, lint, and confirm unit tests all pass before pushing, and now the PR has 100 irrelevant whitespace changes that are going to be reverted by the next pull request. A pre-commit script could gate that and auto fix it but noooo, admins don’t want to turn on a feature they don’t use.
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… :(
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
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.
To be honest, when I ask a candidate about git, I’m looking for them to describe this workflow.
Heck, I have a new person who I tasked with minor config change, just to make sure she knows how to use git in a professional environment
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.
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.
I find the “clean history” argument so flawed.
Sure, if you’re they type to micro commit, you can squash your branch and clean it up before merging. We don’t need a dozen “fixed tests” commits for context.
But in practice, I have seen multiple teams with the policy of squash merging every branch with 0 exceptions. Even going so far as squash merging development branches to master, which then lumps 20 different changes into a single commit. Sure, you can always be a git archeologist, check out specific revisions, see the original commits, and dig down the history over and over, to get the original context of the specific change you’re looking into. But that’s way fucking more overhead than just looking at an unmanipulated history and seeing the parallel work going on, and get a clue on context at a glance at the network graph.
Using curated commits to optimize for pull request reviewability is highly underrated. Liberal use of interactive rebasing to ‘tell a story’, essentially.
you’re they type to micro commit
Thanks for a much shorter and better way to explain this tendency of mine and why I rebase a lot, yoinking this phrase.
