4 ms·

Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!

by mtm7 6y ago

kubanczyk 6y ago
It's actually an answer to a standard interview question. I've met it more than once. Funny thing, nowadays it's going to be deprecated in favor of: git switch -c newbranch
- aprdm 6y ago
  There's an interview question about some behaviour of git that people don't rely on very often? Wow. Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software...
  - deleted 6y ago
    [deleted]
  - james-skemp 6y ago
    > Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software... Why so? We don't go into great depth, but every hiring committee I've been on I make sure that we ask something about source control. You can learn a lot about a developer's process by finding out if and how they use source control. (Red flag, for me, is if an apparent senior dev doesn't use a VCS.)
    - deleted 6y ago
      [deleted]
    - pragmatic 6y ago
      Isn't there a difference between knowing/understanding VCS and git flag trivia? Seems needlessly pendantic?
      - OJFord 6y ago
        Not GP, but if I were, to me 'I can never remember the flags, so I made aliases' is a good answer. (Problem-solving, learning to use tools in a way that works for them, etc.)
      - james-skemp 6y ago
        Whoops. Red flag = warning sign, not anything related to Git flags. OJFord is basically correct, though. It's 2020, so if you're interviewing for a developer/programming position, you should at least know something about the various VCS options. If it helps, during our last set of interviews the question was "What is your strategy when using source control?" Before that was the two part question of "Describe your preferred development environment, both physical and technical. What is one thing in your development process that you can’t live without?" (I always tell the candidate that my answer to this is some sort of VCS.) (These were both for the second, in-person, interview. There's not necessarily a wrong answer. It's not like we're asking them to name as many differences between Git and TFS as they can. :) )
- smichel17 6y ago
  Which is similarly terrible; it should be a flag on the `branch` command, not `switch`. I actually popped on the git development irc channel a few months ago to make this suggestion. The two people I talked to (at least one of whom seemed to be a core developer, although I did not verify this) did not see how, if you're going to conflate the actions of creating a branch and checking it out, it makes more sense to do this as a flag on the primary action, branch creation. They were nice enough to have an in-depth conversion with a complete newcomer, though, so it was not a negative experience overall. Maybe someone else could convince them :)
  - bacon_waffle 6y ago
    Maybe this depends on your mental model of what a git checkout is? To me, "git checkout X" means: update the working directory to reflect X and update HEAD to point at X. (edit: and HEAD means "the branch to update when a new commit is made"). I use "git checkout" a lot more often than "git branch" and "git checkout -b" combined. So, to me, the fact that X is a to-be-created branch is secondary to the primary "checkout" operation. That said, I do vaguely recall this seeming weird at first.
    - smichel17 6y ago
      I'm going to discuss mental models in a separate comment because they're actually more interesting and this comment is getting too long. ---Succinct argument--- What happens if you remove the flag? Put differently, how much does the flag change the semantics? `git branch newbranch` will gracefully fall back to creating a new branch at HEAD. `git checkout newbranch` will fail (error: pathspec 'newbranch' did not match any file(s) known to git), because the regular version of the command involves operating on something that already exists. ---Less succinct further argument--- checkout's `-B` variant. Here's how the man page explains it: > If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of > > $ git branch -f <branch> [<start point>] > $ git checkout <branch> If it were a flag on branch, you wouldn't need a separate flag, just `git branch -fs newbranch` (-s for --switch). Actually, looking through the man page for `checkout` now, I see 4 other options I didn't know about (-t|--track, --no-track, --guess, --no-guess), apparently for the sole purpose of being used with -b. --- I don't think I thought of this argument when I originally chatted in #git-devel, maybe I'll give it another try.
- senderista 6y ago
  Who asks interview questions about git syntax? I’ve never encountered this (in 20 years) and hope I never do.

Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!

by mtm7 6y ago

Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!

It's actually an answer to a standard interview question. I've met it more than once. Funny thing, nowadays it's going to be deprecated in favor of: git switch -c newbranch

aprdm 6y ago
There's an interview question about some behaviour of git that people don't rely on very often? Wow. Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software...
- deleted 6y ago
  [deleted]
- james-skemp 6y ago
  > Asking anything about VCS seems a bit off in general if the person has any experience under their belt developing software... Why so? We don't go into great depth, but every hiring committee I've been on I make sure that we ask something about source control. You can learn a lot about a developer's process by finding out if and how they use source control. (Red flag, for me, is if an apparent senior dev doesn't use a VCS.)
  - deleted 6y ago
    [deleted]
  - pragmatic 6y ago
    Isn't there a difference between knowing/understanding VCS and git flag trivia? Seems needlessly pendantic?
    - OJFord 6y ago
      Not GP, but if I were, to me 'I can never remember the flags, so I made aliases' is a good answer. (Problem-solving, learning to use tools in a way that works for them, etc.)
    - james-skemp 6y ago
      Whoops. Red flag = warning sign, not anything related to Git flags. OJFord is basically correct, though. It's 2020, so if you're interviewing for a developer/programming position, you should at least know something about the various VCS options. If it helps, during our last set of interviews the question was "What is your strategy when using source control?" Before that was the two part question of "Describe your preferred development environment, both physical and technical. What is one thing in your development process that you can’t live without?" (I always tell the candidate that my answer to this is some sort of VCS.) (These were both for the second, in-person, interview. There's not necessarily a wrong answer. It's not like we're asking them to name as many differences between Git and TFS as they can. :) )
smichel17 6y ago
Which is similarly terrible; it should be a flag on the `branch` command, not `switch`. I actually popped on the git development irc channel a few months ago to make this suggestion. The two people I talked to (at least one of whom seemed to be a core developer, although I did not verify this) did not see how, if you're going to conflate the actions of creating a branch and checking it out, it makes more sense to do this as a flag on the primary action, branch creation. They were nice enough to have an in-depth conversion with a complete newcomer, though, so it was not a negative experience overall. Maybe someone else could convince them :)
- bacon_waffle 6y ago
  Maybe this depends on your mental model of what a git checkout is? To me, "git checkout X" means: update the working directory to reflect X and update HEAD to point at X. (edit: and HEAD means "the branch to update when a new commit is made"). I use "git checkout" a lot more often than "git branch" and "git checkout -b" combined. So, to me, the fact that X is a to-be-created branch is secondary to the primary "checkout" operation. That said, I do vaguely recall this seeming weird at first.
  - smichel17 6y ago
    I'm going to discuss mental models in a separate comment because they're actually more interesting and this comment is getting too long. ---Succinct argument--- What happens if you remove the flag? Put differently, how much does the flag change the semantics? `git branch newbranch` will gracefully fall back to creating a new branch at HEAD. `git checkout newbranch` will fail (error: pathspec 'newbranch' did not match any file(s) known to git), because the regular version of the command involves operating on something that already exists. ---Less succinct further argument--- checkout's `-B` variant. Here's how the man page explains it: > If -B is given, <new_branch> is created if it doesn’t exist; otherwise, it is reset. This is the transactional equivalent of > > $ git branch -f <branch> [<start point>] > $ git checkout <branch> If it were a flag on branch, you wouldn't need a separate flag, just `git branch -fs newbranch` (-s for --switch). Actually, looking through the man page for `checkout` now, I see 4 other options I didn't know about (-t|--track, --no-track, --guess, --no-guess), apparently for the sole purpose of being used with -b. --- I don't think I thought of this argument when I originally chatted in #git-devel, maybe I'll give it another try.
senderista 6y ago
Who asks interview questions about git syntax? I’ve never encountered this (in 20 years) and hope I never do.