Because LLMs aren't a reason to not learn your tools. A determinist CLI command vs using a statistical machine for it. It's just a waste of tokens at the very least.
add_github_remote() {
git remote add $1 [email protected]:$2/$3.git
}2. Give your shell functions a common prefix, and/or big-endian naming convention (e.g. things that help you with git start with `@git-`)
3. Tab completion is your friend.
Some 6-figure per year developer spending a dime’s worth of tokens to do something they do once a month or so is not something I’ll ever care to optimize away…
I don't disagree that having a deterministic CLI is useful, but I'd argue that's not the question here, because the CLI is what the statistical machine will be using. The question is whether the time spend doing it manually is worthwhile compared to the tokens spend on it. I'd argue that if you instead learn how to pick the right model for the right job so that you don't use something way more expensive than needed for the task at hand, the token overhead will be extremely minimal for stuff like git operations; knowing that you can use something cheaper than like, Astra or Opus if all you want to do is a quick git cleanup and push is going to save your employer a lot more money in the long run than if you insist on doing every messy rebase by hand.
In terms of team practices, that basically seems like a code review thing. If my team has conventions around git, and a PR doesn't fit them, that's something I would point out regardless of how the PR was generated. If a team member is repeatedly not meeting the expectations we've all agreed upon, I would deal with it in the same way I always have; reach out and offer guidance for how to do things the way they're supposed to, notify my manager if they continue having trouble with it, and eventually just not bother looking at their PRs if they absolutely refuse to do things the way everyone else on the team has agreed they should be done.
Even if an LLM can hold your hand through everything, the disruption I've had because people don't understand what the LLM tool is doing, and ultimately does damage (we've had repos corrupted, systems taken offline, systems brought their knees, numerous data security incidents... it's been a fucking nightmare) is immense.
Even worse, it gave a developer a command to run that basically crushed all history across all branches, it was a mess to clean up and lost a significant amount of work. It wasn't Claude running it on its own, but was entirely driven by a mix of a developer's lack of understanding their tools, and trusting Claude's output too much.
This was also the dev trying to "remove a key he had accidentally committed" again, just letting Claude take the wheel.
Of course, the new team _also_ really loved leaning on AI so they were all behind his plan to "clean up the repo" and not just reset the key and move on.
It was a nightmare.
One time setup commands are the sort of thing people do once when setting up the repo, but dont use day to day. its understandable that people dont have that memorized and will reach for a man page, google or an AI.
Though ideally interviewers should appreciate this - unless its a hard requirement you do it by hand day to day - the rest of us can look this up quick enough.
My OS professor in college once told us about what he considered the difference between "knowledge" and "information", with "knowledge" being the underlying facts about how something works and "information" being the terminology/labeling/bucketing/etc. of how to refer to it. The point he made was that knowledge was more important than information, and that he would try to test us on knowledge rather than information. To me, knowing how the underlying version control model works and what "shapes" you might want to make with it is useful knowledge. The exact set of commands, interactions with an IDE, or specific prompts you can use to ask an LLM to produce them is information. Arguably the entire benefit of LLMs is that you can ask them to do things even if you don't have the exact information memorized; if you can describe it in a rigorous way, and recognize whether what it gives you as an output fits that or not, you don't need to know any of the actual information of how to do it manually.
jj? what's that?
I wish better names would be chosen by the tech industry, that would make search engine discoverability easier.
WHERE?! This is the first time I'm hearing about it.
They... are?
https://www.google.com/search?aep=11&udm=50&q=should+you+swi...
You can't google for "X" like it's early stack overflow days, but adding the minimum context "X that has something to do with Y" works 99% of the time.
> The command-line tool is called jj for now because it's easy to type and easy to replace (rare in English). The project is called "Jujutsu" because it matches "jj".
There is no way to verify it just by talking.
like, i dont really need to know all the stash details when i only stash one thing at a time, very temporarily
i also dont really care to know all the origin and remote definitions stuff when i only touch it once per project or so.
i could certainly draw graphs of what different git repos look like, but what makes it salient to know the rest of the details unless im actually building git itself? if youre using every git feature regularly you're probably doing something wrong
If I were hiring, I would care about whether you can `git help stash`, skim over it (bonus points for actually using the pager competently) and figure out what you need to do.
I couldn’t care less about stashing commands.
I do care about … if someone understands origins and not by definition because developer needs to know what is his local version and what is on the server and how those two affect each other. Bonus points if they understand server is not special in Git and their colleagues copy on their laptop can be origin as well.
Drawing graphs of what different repos look like? That’s irrelevant.
Irrelevant if one understands that Git uses DAG and is content addressable store.
You see someone might know those hard words but when working daily with Git reasoning about rebase or merge, cleaning up their own work with interactive rebase, making pull/merge requests or resolving conflicts it is much easier if one knows what is local what is remote and how Git stores data.
You also learn it once. In my 15 years of using Git I basically didn’t learn much new commands but having mental model of how it works was my tool to fix any problems other people had. Knowing commands or definitions is secondary.
Now I just ask google, and I get a straightforward "do this", and it works.
That's the thing, though. Stack Overflow is not and never was intended to solve your problem, nor to solve the OP's problem. It was intended to answer questions. It was your responsibility, both as someone posting a question and as someone reading the Q&A later, to adapt knowledge to your circumstances. That's why they're called questions and answers, and are not called problems and solutions.
People who use a web site to get a solution to a problem are looking for a help desk, or a forum. Stack Overflow was specifically created to be not that, and that choice was specifically motivated by the frustration people had with trying to search those kinds of sites for information, and the frustration that experts had with trying to help people (for free) in that kind of environment.
Personally I ask the LLM to summarise what the commit does and explain it to me, make sure I understand it, then review the PR. I'm getting half the speed the High Speed Sloperators are getting but I was the only person submitting PRs the other day when the LLM service was down.
For nasty multi-way git merges and rebases, it's been a game changer. And of course that's reviewable by doing a delta on the final rebase branch vs. the original branch.
With all that said... having to use LLMs at work is making me want to use them less on my own projects.
For the more important changes, I find it easier to stay on my toes by taking a pass at the codebase before comparing notes with the LLM. Looking up the answer key first makes it too easy to nod uncritically.
Git is an essential tool; not knowing how a key tool works is dangerous IMO
I have not run a single git command in like the entire 2026.
Should you resolve the conflicts in a bad way we're going to see the result in the MR, will we not?
I don't think git knowledge is essential anymore.
Back in the days of the crappy git GUIs this was a problem, because people would regularly misunderstand even the basics of what they were doing and managed to lose their local changes.
That shouldn't happen with LLMs.
Because someone who's familiar with those sorts of things can get the commands typed and running before someone who isn't has even figured out the prompt.
(Well, not so much if there's a need to identify the base commit for a squash, do some cherry-picking, etc. But in those cases I'd rather see direct human judgment of what to do than hoping the LLM understands a vague description.)