{"thread":{"id":"16972","subject":"\"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???","startedAt":"2009-01-02T19:57:24Z","lastAt":"2009-01-03T12:27:25Z","messageCount":5,"participants":["chris@seberino.org","Junio C Hamano","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"99198","messageId":"20090102195724.GA23119@seberino.org","threadId":"16972","inReplyTo":null,"subject":"\"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???","fromName":"","fromEmail":"chris@seberino.org","sentAt":"2009-01-02T19:57:24Z","receivedAt":"2009-01-02T19:57:24Z","isPatch":false,"sender":{"key":"chris@seberino.org","avatar":null},"body":"Does \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???\n\nIt seems we have 2 ways to blow away work we haven't checked in yet then right?\n\nchris\n"},{"id":"99220","messageId":"7v4p0hcp3w.fsf@gitster.siamese.dyndns.org","threadId":"16972","inReplyTo":"20090102195724.GA23119@seberino.org","subject":"Re: \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-02T22:36:19Z","receivedAt":"2009-01-02T22:36:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"chris@seberino.org writes:\n\n> Does \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???\n\nNo, but \"reset --hard\" without a commit-ish defaults to HEAD so the first\none and the last one are equivalent.\n\n> It seems we have 2 ways to blow away work we haven't checked in yet then right?\n\nWrong.\n"},{"id":"99240","messageId":"slrngltvrd.63u.sitaramc@sitaramc.homelinux.net","threadId":"16972","inReplyTo":"7v4p0hcp3w.fsf@gitster.siamese.dyndns.org","subject":"Re: \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-03T06:02:21Z","receivedAt":"2009-01-03T06:02:21Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-02, Junio C Hamano wrote:\n> chris@seberino.org writes:\n>\n>> Does \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???\n>\n> No, but \"reset --hard\" without a commit-ish defaults to HEAD so the first\n> one and the last one are equivalent.\n>\n>> It seems we have 2 ways to blow away work we haven't\n>> checked in yet then right?\n>\n> Wrong.\n\nStrictly as asked, yes, but what if he adds a \"-f\" to the\nmiddle command, making it \"git checkout -f HEAD\"? Wouldn't\nthat be the same as the others then?\n\nI always thought they were eqvt...\n"},{"id":"99243","messageId":"7vprj4ae5y.fsf@gitster.siamese.dyndns.org","threadId":"16972","inReplyTo":"slrngltvrd.63u.sitaramc@sitaramc.homelinux.net","subject":"Re: \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-03T10:15:37Z","receivedAt":"2009-01-03T10:15:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sitaram Chamarty writes:\n\n>>> It seems we have 2 ways to blow away work we haven't\n>>> checked in yet then right?\n>>\n>> Wrong.\n>\n> Strictly as asked, yes, but what if he adds a \"-f\" to the\n> middle command, making it \"git checkout -f HEAD\"? Wouldn't\n> that be the same as the others then?\n\nYeah, but comparing reset and checkout misses a whole _dimension_ in the\nrevision space continuum.\n\n\"git checkout \" is primarily about checking out a different\nbranch, aka \"switching branches\".\n\nWhen you switch branches, you generally do not want to lose your pending\nchanges, but would want to take them with you. A typical scenario is that\nyou start looking at one issue, you fiddle a few lines here and twiddle a\nfew lines there, and as you dig deeper, you realize that whatever the\nfinal shape of the change you are going to make will be either (1) big\nenough to deserve its own branch created anew, or (2) better done as an\nextension to an existing branch. You realize that you are in the latter\nsituation by noticing that the modification you were making will be helped\nby something you have implemented in the other branch but not yet\navailable in the current one (typically the latter is 'master').\n\nIn such a case, you will \"git checkout \" to switch\nto the branch, and you would want to take the change you already made to\nyour work tree files when you do so.\n\nOn the other hand, \"git checkout -f \" blows away your changes, but\nit still _is_ about switching to a different branch.\n\nWhether you use -f or not, you are allowed to ask to switch to the current\nbranch by (1) naming the branch explicitly, i.e. \"git checkout -f master\",\n(2) using HEAD to mean the current one instead, or (3) omitting \naltogether. But that is there merely for consistency and, even though\nthere may not make much sense to do so (because it is largely no-op except\nthat you would get the \"you are ahead by N\" notice), there is no strong\nreason to forbid asking for a no-op.\n\nFor that reason, \"git checkout -f HEAD\" is \"blow away my changes\". But it\nis merely a degenerated case of \"switching to the current branch while\nblowing away my changes.\"\n\n\"git reset --hard \" is different. \"reset\" is primarily about\npointing the tip of the current branch to somewhere else. While \"git\ncheckout \" never changes what commit sits at the tip of any\nbranch, \"git reset \" modifies it for the current branch (--hard\nvariant matches the work tree files to the contents recorded by the\nresetted-to commit while at it).\n\nAgain, you are allowed to ask to reset to the current HEAD by saying\n\"reset --hard HEAD\". That is a degenerated case of \"resetting the tip of\nthe current branch, while blowing away my changes\". More general case\nwould be \"reset --hard \" and it won't just blow away your\nchanges (relative to the commit you started out with), but also blows away\nthe history leading to the commit the branch tip used to point at.\n\n\"checkout -f\" and \"reset --hard\" work on different dimensions, and what\nthey do intersect when (and only when) the / argument\nhappen to be HEAD. \"checkout -f \" and \"reset --hard \"\nwill do quite different things.\n"},{"id":"99250","messageId":"slrnglumdd.erd.sitaramc@sitaramc.homelinux.net","threadId":"16972","inReplyTo":"7vprj4ae5y.fsf@gitster.siamese.dyndns.org","subject":"Re: \"git reset --hard\" == \"git checkout HEAD\" == \"git reset --hard HEAD\" ???","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2009-01-03T12:27:25Z","receivedAt":"2009-01-03T12:27:25Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2009-01-03, Junio C Hamano wrote:\n> Sitaram Chamarty writes:\n>\n>>>> It seems we have 2 ways to blow away work we haven't\n>>>> checked in yet then right?\n>>>\n>>> Wrong.\n>>\n>> Strictly as asked, yes, but what if he adds a \"-f\" to the\n>> middle command, making it \"git checkout -f HEAD\"? Wouldn't\n>> that be the same as the others then?\n>\n> Yeah, but comparing reset and checkout misses a whole _dimension_ in the\n> revision space continuum.\n\n[snip]\n\n> \"checkout -f\" and \"reset --hard\" work on different dimensions, and what\n> they do intersect when (and only when) the / argument\n> happen to be HEAD. \"checkout -f \" and \"reset --hard \"\n> will do quite different things.\n\nI teach git sometimes (internally) in my job. It seems to\nme that people who don't like TMTOWTDI get stuck on this\n\"why are there 2 ways to do the same thing\" aspect, even\nafter I explain all the *other* uses of the two commands to\nshow that they're actually quite different!\n\nYour use of \"dimension\" and \"degenerate case\" gave me an\nidea... most of my audience have decent math skills, so I\nbet they get it if I say these are like two quite different\nfunctions that just happen to intersect at x=0 :-)\n\nThank you very much!\n"}]}