{"thread":{"id":"31484","subject":"git checkout -b following git reset --hard pitfall","startedAt":"2012-09-09T13:25:48Z","lastAt":"2012-09-09T13:57:03Z","messageCount":2,"participants":["Maris, Rob","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"198627","messageId":"op.wkdd9andsuzgrs@rob-desktop","threadId":"31484","inReplyTo":null,"subject":"git checkout -b following git reset --hard pitfall","fromName":"Maris, Rob","fromEmail":"maris.rob@ingenieur.de","sentAt":"2012-09-09T13:25:48Z","receivedAt":"2012-09-09T13:25:48Z","isPatch":false,"sender":{"key":"maris.rob@ingenieur.de","avatar":null},"body":"Normally, when there are modifications in the working tree not yet added  \nresp. committed, git will refuse to change to another branch.\nHowever, when I create a new branch on the fly, using git checkout -b  \n<branch>, there is no complaint appearing. After doing so, I executed a  \ngit reset --hard in once case, just thinking that the previous \"modified\"  \nbranch status was preserved. Of course, this notion is incorrect. But I  \nrealised this after a bit of thinking about it. Actually, the modified  \nstatus of git related to both branches after git checkout -b can have  \nfollowing consequences:\n\n- it is lost definitely when git reset -hard is executed\n- if committed, it is committed into the newly created branch\n\nThis actually constitutes an asymmetric response (perceived double  \ndeletion vs. single preservation).\nI'd wish that git checkout displays *at least* a warning when a \"modified\"  \nstate is not committed:  \"warning: Your local changes to the following  \nfiles are no longer associated with the previous branch:\"\n\n-Rob\n\ngit version 1.7.11\n"},{"id":"198629","messageId":"m2mx0z47v4.fsf@igel.home","threadId":"31484","inReplyTo":"op.wkdd9andsuzgrs@rob-desktop","subject":"Re: git checkout -b following git reset --hard pitfall","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-09-09T13:57:03Z","receivedAt":"2012-09-09T13:57:03Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"\"Maris, Rob\" <maris.rob@ingenieur.de> writes:\n\n> Normally, when there are modifications in the working tree not yet added\n> resp. committed, git will refuse to change to another branch.\n\nOnly if switching the branch requires touching the modified files.\n\n> Actually, the modified\n> status of git related to both branches after git checkout -b can have\n> following consequences:\n>\n> - it is lost definitely when git reset -hard is executed\n\nThis is true regardless.\n\n> - if committed, it is committed into the newly created branch\n\nThis is often the desired state, and there is no harm in doing it\naccidentally.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"}]}