Kevin Bracey <> wrote:
> On 01/06/2014 07:26, Atsushi Nakagawa wrote:
> > Kevin Bracey <> wrote:
> >> The original "git reset --hard" used to be a pretty top-level command.
> >> It was used for aborting merges in particular. But I think it now
> >> stands out as being one of the only really dangerous porcelain
> >> commands, and I can't think of any real workflow it's still useful
> >> for.
> > My thoughts exactly.  I think the 'reset --soft/--mixed/--hard' pattern
> > is so ingrained, that many people just don't realize there's a safer
> > alternative.  (I've heard work mates on more than one occasion
> > recommending 'reset --hard' as the go-to command for discarding commits.)
> >
> > I believe this is likely because many third party GUI tools just don't
> > support 'reset --keep', and these tools present a "Reset..." dialog with
> > the de facto Soft/Mixed/Hard options.  (Even 'gitk' does this.)
> True on the GUI - "hard" really needs demotion.
> It would help if the documentation explained better straight off what
> the different reset modes are intended /for/ in a more practical way,
> rather than the technical jargon.

On one hand, I agree that improving man git-reset and making it easier
to understand would be of benefit.

However, one of the main culprits of confusion here seems to be the mere
existance of '--keep', which is somewhat of a conceptual black sheep.

The --soft/--mixed/--hard trio seems quite easy to explain, /if/ you
didn't need to also explain --keep...

To that end, I'm wondering if it's better to just deprecate 'reset
--keep' and shift the use-case over to 'checkout':

checkout [-u|--update] [<commit>|<branch>]

    Rather than checking out a branch to work on it, check out a commit
    and reset the current branch to that commit.

    This is functionally equivalent to 'checkout -B CURRENT_BRANCH <commit>'.

    (...Maybe a warning here about commits becoming unreachable...)

Then, as an added bonus, anything I've staged is kept intact.  *And*, I
can attempt 'checkout -u --merge' if I'm feeling particulary careless.

> --hard
>     All [] changes are dropped[] and the [working tree] and index are
>     forcibly reset to the [state of <commit>].  Note that this is
>     dangerous if used carelessly.  ALL uncommitted changes to ALL
>     tracked files will be lost[].
>     Older documentation often recommends "git reset --hard" to
>     undo commits; the newer "--keep" option is [safer and is now the
>     recommended] alternative [for use in this situation].

I like this explaination of '--hard' and prefer it over current, which
doesn't much explain the gravity of the command.  I've made some edits

> --merge
>     Performs the operation of "git merge --abort", intended for use
>     during a merge resolution - see git-merge(1) for more information.
>     This form is not normally used directly.

Aha, so that's what that's for.  I couldn't really understand the
explanation in the current manpage, but your version at least tells me
that it's an option I don't need to worry about.


Atsushi Nakagawa
Changes are made when there is inconvenience.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to