git checkout -b following git reset --hard pitfall
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
Quoted 2 lines · Rob
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.
Quoted 5 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.
Quoted 1 line
- 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.
Signature · 3 lines
Andreas Schwab, [email protected] GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."