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

Re: git checkout -b following git reset --hard pitfall

From
Andreas Schwab <schwab@linux-m68k.org>
Date
Sep 9, 2012, 13:57 UTC
Message-ID
<m2mx0z47v4.fsf@igel.home>
In-Reply-To
<op.wkdd9andsuzgrs@rob-desktop>
"Maris, Rob" <maris.rob@ingenieur.de> writes:
> Normally, when there are modifications in the working tree not yet added
> resp. committed, git will refuse to change to another branch.
Only if switching the branch requires touching the modified files.
Show 5 quoted lines
> 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
This is true regardless.
> - if committed, it is committed into the newly created branch

This is often the desired state, and there is no harm in doing it accidentally.

Andreas.
-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Previous: Maris, Rob
Message 2 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.