Felipe Contreras <felipe.contre...@gmail.com> 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 would help.
>  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.
Changes are made when there is inconvenience.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html