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.
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.