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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html