Kevin Bracey <[email protected]> wrote:
> On 01/06/2014 07:26, Atsushi Nakagawa wrote:
> > Kevin Bracey <[email protected]> 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>]
-u
--update
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
above.
> --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.
Cheers,
--
Atsushi Nakagawa
<[email protected]>
Changes are made when there is inconvenience.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
