threads / discuss / 31484

git checkout -b following git reset --hard pitfall

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

## tl;dr

2 messages between Sep 9, 2012 and Sep 9, 2012.

replies: 1people: 2as markdown or json

Maris, Rob· Sep 9, 2012, 13:25 UTC · lore

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

Andreas Schwab· Sep 9, 2012, 13:57 UTC · re: Maris, Rob · lore

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

"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."