Sitaram Chamarty <sitaramc@xxxxxxxxx> writes: >>> It seems we have 2 ways to blow away work we haven't >>> checked in yet then right? >> >> Wrong. > > Strictly as asked, yes, but what if he adds a "-f" to the > middle command, making it "git checkout -f HEAD"? Wouldn't > that be the same as the others then? Yeah, but comparing reset and checkout misses a whole _dimension_ in the revision space continuum. "git checkout <branch>" is primarily about checking out a different branch, aka "switching branches". When you switch branches, you generally do not want to lose your pending changes, but would want to take them with you. A typical scenario is that you start looking at one issue, you fiddle a few lines here and twiddle a few lines there, and as you dig deeper, you realize that whatever the final shape of the change you are going to make will be either (1) big enough to deserve its own branch created anew, or (2) better done as an extension to an existing branch. You realize that you are in the latter situation by noticing that the modification you were making will be helped by something you have implemented in the other branch but not yet available in the current one (typically the latter is 'master'). In such a case, you will "git checkout <the-appropriate-topic>" to switch to the branch, and you would want to take the change you already made to your work tree files when you do so. On the other hand, "git checkout -f <branch>" blows away your changes, but it still _is_ about switching to a different branch. Whether you use -f or not, you are allowed to ask to switch to the current branch by (1) naming the branch explicitly, i.e. "git checkout -f master", (2) using HEAD to mean the current one instead, or (3) omitting <branch> altogether. But that is there merely for consistency and, even though there may not make much sense to do so (because it is largely no-op except that you would get the "you are ahead by N" notice), there is no strong reason to forbid asking for a no-op. For that reason, "git checkout -f HEAD" is "blow away my changes". But it is merely a degenerated case of "switching to the current branch while blowing away my changes." "git reset --hard <commit>" is different. "reset" is primarily about pointing the tip of the current branch to somewhere else. While "git checkout <branch>" never changes what commit sits at the tip of any branch, "git reset <commit>" modifies it for the current branch (--hard variant matches the work tree files to the contents recorded by the resetted-to commit while at it). Again, you are allowed to ask to reset to the current HEAD by saying "reset --hard HEAD". That is a degenerated case of "resetting the tip of the current branch, while blowing away my changes". More general case would be "reset --hard <some-commit>" and it won't just blow away your changes (relative to the commit you started out with), but also blows away the history leading to the commit the branch tip used to point at. "checkout -f" and "reset --hard" work on different dimensions, and what they do intersect when (and only when) the <branch>/<commit> argument happen to be HEAD. "checkout -f <another>" and "reset --hard <another>" will do quite different things. -- 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
