On 2009.06.13 01:30:38 +0300, Felipe Contreras wrote: > On Sat, Jun 13, 2009 at 1:05 AM, Jakub Narebski<jnareb@xxxxxxxxx> wrote: > > On Fri, 12 Jun 2009, Felipe Contreras wrote: > >> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski<jnareb@xxxxxxxxx> wrote: > > > >>> Nope. 'git reset' always reset some part of state to a given commit, > >>> HEAD by default. It can reset current branch with --soft, branch plus > >>> index with --mixed (default), and branch plus index plus working > >>> directory with --hard. Source is always commit. > >> > >> You said it: 'git reset --hard' gets something out of the repository > >> and into the working directory. > >> > >> Try this: > >> git checkout <random sha-1 with no ref> > >> > >> Then what is the difference between: > >> git checkout HEAD^ > >> git reset --hard HEAD^ > >> > >> In this case they do exactly the same thing, don't they? > > > > No, they don't. "git checkout HEAD^" modifies HEAD detaching it. > > "git reset --hard HEAD^" modifies branch that HEAD points to (well, > > unless HEAD is detached). > > Read again: > >> git checkout <random sha-1 with no ref> > > The HEAD is detached, so they do exactly the same in this case. Not if there are uncommitted changes to tracked files. Björn -- 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