Hacker News Reader

Comment by ph0rque | Hacker News Reader

Good advice. I would add the following use case:

    # Oh no! Those changes should have been on their own branch, not dev...
    git stash
    git checkout -b changes_on_their_own_branch
    git stash apply
    git commit -a

View on HN

That is overly verbose. Try this:

    git checkout -b changes_on_their_own_branch
    git commit -a

You can always create a new branch at HEAD (where you are currently) and switch to it without having to stash.

On the other hand, stashing may be required if you wanted your branch to start elsewhere:

    git checkout -b changes_branch start_point

But doesn't git stop you from switching to another branch when there are uncommitted changes?

As GP said, not if you're creating a new branch. There's no history in the new branch to potentially overwrite your uncommitted changes in the working tree, so nothing for it to object to.

Git only prevents switching branches if the act of switching branches would modify the files you have uncommitted changes to. In the case of fr0sty's suggestion, the new branch cannot have any changes because it's being created from the current HEAD. But even if you're switching to a pre-existing branch, it may still work depending on what files git will need to touch.

In other words, no harm in trying the `git checkout other_branch` first, and only stashing if that fails.

Reply on news.ycombinator.com