Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > Felipe Contreras wrote: > > Atsushi Nakagawa wrote: > > > Ok, the typical use case is: I'm on 'master' and I make a few test > > > commits. Afterwards, I want to discard the commits and move back to > > > 'origin/master'. I could type 'reset --hard origin/master' and risk > > > blowing away dirty files if I'm not careful. Or, I could use "reset by > > > checkout" and be carefree. > > > > Doesn't 'git reset orign/master' do that? > > Unless you want to keep the staged files, in which case adding the > --stage and --work options I originally suggested[1] would help. > ... > > [1] http://article.gmane.org/gmane.comp.version-control.git/247086 What I was looking for is basically what 'git checkout' does to the working tree when it moves from one commit to another, as well as the semantic checks it offers such that I'm incapable of making an unrecoverable change (i.e. It aborts if I'm about to blow away changes that aren't committed.). I was introduced to 'git reset --keep' in another reply and that for most intent and purpose is what I think I was after. Cheers, -- Atsushi Nakagawa <atnak@xxxxxxxxx> Changes are made when there is inconvenience. -- 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