git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git checkout -b following git reset --hard pitfall

From
MRMaris, Rob <maris.rob@ingenieur.de>
Date
Sep 9, 2012, 13:25 UTC
Message-ID
<op.wkdd9andsuzgrs@rob-desktop>

Normally, when there are modifications in the working tree not yet added resp. committed, git will refuse to change to another branch. However, when I create a new branch on the fly, using git checkout -b <branch>, there is no complaint appearing. After doing so, I executed a git reset --hard in once case, just thinking that the previous "modified" branch status was preserved. Of course, this notion is incorrect. But I realised this after a bit of thinking about it. Actually, the modified status of git related to both branches after git checkout -b can have following consequences:

- it is lost definitely when git reset -hard is executed
- if committed, it is committed into the newly created branch

This actually constitutes an asymmetric response (perceived double deletion vs. single preservation). I'd wish that git checkout displays *at least* a warning when a "modified" state is not committed: "warning: Your local changes to the following files are no longer associated with the previous branch:"

-Rob
git version 1.7.11
Next: Andreas Schwab
Message 1 of 2 in “git checkout -b following git reset --hard pitfall”
  1. Maris, RobSep 9, 2012
  2. Andreas SchwabSep 9, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.