Re: Reset by checkout?

> Kevin Bracey <kevin@bracey.fi> wrote:
>> On 01/06/2014 07:26, Atsushi Nakagawa wrote:
>> > Kevin Bracey <kevin@bracey.fi> 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.
>