7 ms·

> Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default. git checkout -b new-branch I fairly o

> Why would I ever want to make a branch without checking it out? It's literally never happened, yet it's the default. git checkout -b new-branch I fairly often make a branch as a sort of named undo point, and only check it out if need to undo to that point. Tags could work for that purpose too, but the branch approach seems safer in my usual work situation.

mtm7 6y ago
Wow, I’d never thought of using it like this. Thanks for sharing, I just added something new to my workflow!
- 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.
dreamcompiler 6y ago
> I fairly often make a branch as a sort of named undo point Could you say more about this? I use git checkout -b new-branch all the time, but that checks it out. What does "using an un-checked-out branch as an undo point" mean? Don't you have to check it out to commit changes to it? I suppose I could read the docs but the git docs are awful.
- hellofunk 6y ago
  It creates the branch immediately for your last commit on your current branch. Therefore you have just named an undo point you could use later.
- bacon_waffle 6y ago
  Occasionally I find it handy to tentatively do a rebase or similar, where I'm confident that the rebase itself will succeed but not so confident that the result will be something that I want to keep. In that case, making a branch at the current commit (using "git branch new-undo-point") will leave an easy way to return to the current state as if the rebase never happened. Recently, in explaining this to a colleague who's relatively new to git, I think the "aha" moment came in realising that if you rewrite the history leading to commit X, you're really making new commit Y in addition to the old commit X - you're not changing X in to Y. Leaving a branch pointing at X is enough that git will keep it around after the history rewriting, in case you decide to do something with it later.
  - dreamcompiler 6y ago
    Ah. I get it. You're talking about using a new branch name as a tag for an existing commit. Thanks.
- deleted 6y ago
  [deleted]
brianpan 6y ago
I seem to make tracking branches just as often. git checkout -t remote-branch

mtm7 6y ago

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

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.

dreamcompiler 6y ago

> I fairly often make a branch as a sort of named undo point Could you say more about this? I use git checkout -b new-branch all the time, but that checks it out. What does "using an un-checked-out branch as an undo point" mean? Don't you have to check it out to commit changes to it? I suppose I could read the docs but the git docs are awful.

hellofunk 6y ago
It creates the branch immediately for your last commit on your current branch. Therefore you have just named an undo point you could use later.
bacon_waffle 6y ago
Occasionally I find it handy to tentatively do a rebase or similar, where I'm confident that the rebase itself will succeed but not so confident that the result will be something that I want to keep. In that case, making a branch at the current commit (using "git branch new-undo-point") will leave an easy way to return to the current state as if the rebase never happened. Recently, in explaining this to a colleague who's relatively new to git, I think the "aha" moment came in realising that if you rewrite the history leading to commit X, you're really making new commit Y in addition to the old commit X - you're not changing X in to Y. Leaving a branch pointing at X is enough that git will keep it around after the history rewriting, in case you decide to do something with it later.
- dreamcompiler 6y ago
  Ah. I get it. You're talking about using a new branch name as a tag for an existing commit. Thanks.
deleted 6y ago
[deleted]

brianpan 6y ago

I seem to make tracking branches just as often. git checkout -t remote-branch