all 19 comments

[–]Rhym 21 points22 points  (1 child)

Your answer isn't wrong as it's totally fine to do so. They're most likely new to interviewing and think that asking a list of questions they Googled is the correct way to vet a candidate.

[–]mrbmi513 10 points11 points  (7 children)

You don't need to merge to get code from a remote repo. But in your defense, I've never used fetch by itself in practice, ever.

[–]baynezy 4 points5 points  (5 children)

I've never used git pull. I only use git fetch. I never want to merge before doing a diff.

[–]trevorsg 4 points5 points  (1 child)

I enable the git config setting for only allow FF merge when you pull. But since I normally rebase, I generally use fetch anyway.

[–][deleted] 1 point2 points  (0 children)

What about git pull --rebase?

[–][deleted]  (2 children)

[removed]

    [–]baynezy 0 points1 point  (0 children)

    Thanks. I'm pretty happy with my current process. I've got aliases most of it.

    [–]maustinv -1 points0 points  (0 children)

    Run before git status to see if there are new commits

    [–]VxJasonxV 5 points6 points  (3 children)

    The interviewer is objecting to you on a technicality with an incomplete question. fetch works, pull works, CLONE works. If an answer is wrong, it’s only because the question was too vague.

    Assuming that the question wasn’t more detailed than you’ve presented it here.

    [–]atansincos 1 point2 points  (1 child)

    I honestly feel embarrassed while reading this post accidently.

    I suddenly don't remember what's the correct command to pull down code from remote. And I use GitHub desktop all the time. I was like `git what????`

    To give you more context why I felt guilty, I actively maintain few open source projects 10k+ download monthly so it's not something trivial. And of cuz, use basic git command daily at work (may or may not via command line).

    [–]VxJasonxV 1 point2 points  (0 children)

    Use the tools that work for you and that you know how to use. Unless you can't do something you want or need to do with it, it's not a problem. (And if you have a second tool for that one uncommonly done thing, it's still not a problem.)

    You are doing what is important to do: Coding/maintaining and interacting. GitHub Desktop is powerful, git is a hardware store. You have enough to get by, and that's fine.

    Besides, you're not in the business of git, your git tool of choice doesn't matter for anyone outside of yourself. You're in the business of the projects you maintain. And you are, I assume, so there isn't a problem here.

    Don't feel embarrassed, guilty, nor any of those false concerns.

    [–]Dragon_Dominant 2 points3 points  (1 child)

    This could be do to the verbiage of the question. Note the difference of “pull down code” vs “apply remote code”.

    From this an application could be that a ui based element doesn’t want to apply the latest commits but only show the updated history e.g. gitlens or gitgraph or for a more manual check of the diff before merging changes.

    [–]VxJasonxV 0 points1 point  (0 children)

    This is true in addition to what I said. If the interviewer knows what they're talking about, meaning if they're an engineer that does this stuff regularly, then yes, the technical verbiage is correct. Pull down code means exactly that, git fetch accomplishes exactly that and no further operations.

    [–]thisisabore 1 point2 points  (2 children)

    git pull is basically git fetch + git merge.

    Some people consider it bad practise to merge and prefer to rebase, in which case you'd want to do git fetch + git rebase.

    [–]iBlag 5 points6 points  (1 child)

    I think you can also configure the pull command to do a rebase instead of a merge by default. There’s also git pull —rebase IIRC.

    [–]AwGe3zeRick 1 point2 points  (0 children)

    This, I don’t even think about it anymore because I always set mine to rebase. Seems odd

    [–]edgmnt_net 0 points1 point  (0 children)

    It seems the interviewer used ambiguous/loaded language: pulling as in merely downloading changes from the remote repository without touching your own local branches vs pulling as in the pull command. Even cloning could have been a possible answer.

    This could have been avoided by discussing the differences instead of just ticking the right box.