I get what you are saying about this being easily available information. However, an interviewer might still view this simple test as demonstrating a character flaw.
Rebase is a very basic and common command available in a tool you use every day. That you both don't ever use it and don't know how it works might signal to the interviewer a lack of curiosity. They may think you tend to dismiss options without really considering them in favour of what is familiar.
> Rebase is a very basic and common command available in a tool you use every day.
That says a lot about you, not the people you are interviewing. Not everyone uses or trusts rebase workflows. I think --first-parent is a far better "basic and common command argument" and better makes use of the power of git's DAG. I have it in some of my default gitconfig files. Can you tell me without looking it up what is --first-parent and when and how you would use it? Some of the teams I've been on could. Others are happy with their (in my considered opinion, hideous) rebase or squash workflows. It's an aesthetic choice as much as a "right" choice to know one workflow over the others. [0] We all have our own workflows and most of us can learn new ones when we join a new team.
[0] Barring of course that rebase/squash hides merge conflict resolutions under the rug and trying to reverse engineer mistakes in them is a nightmare, and there's a deep dark rabbit hole from there into darker nightmares like rerere caches. I'm happy to claim that learning DAG traversal tools is not just aesthetically better but objectively safer, especially with junior developers around, but you don't have to take my word for it so let's call it just an "aesthetic choice" to stay on good terms.
I work with too many tools to sit there and memorize the implementation of each of their functions should I be questioned. Either way, its a wasted effort memorizing that considering its all documented should I need to use it. I’ve probably read what was written on rebase at least once by now but I don’t work in shared repos and keep things pretty organized so I don’t need to use it.
Documentation is easy to read after you’ve read enough of it like any other technical writing. It only takes a moment to consult it and know the ground truth.
No one said anything about the implementation of the function. Not understanding what rebase is and does would imply not understanding how git actually works.
For example you mentioned that you know what git pull does. Are you aware that depending on the settings it is either doing a merge or a rebase? I also suspect that is the answer the OP was angling at.
To me we are getting a bit away from the point and going into semantics. My point is and was that being tested on easily reference-able knowledge you are able to look up on the job to no penalty is a waste of everyone’s time, in contrast to the gp who stated failing such test in hiring would lead to perhaps not getting the job on account of it.
Rebase is a very basic and common command available in a tool you use every day. That you both don't ever use it and don't know how it works might signal to the interviewer a lack of curiosity. They may think you tend to dismiss options without really considering them in favour of what is familiar.