Re: Reset by checkout?

["Philip Oakley" <philipoakley@iee.org>]

From: "Atsushi Nakagawa" <atnak@chejz.com>
> 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.
>

Just to say there has been a similar confusion about 'git reset' 
reported on the Git Users group for the case of reset with added 
(staged), but uncommitted changes being wiped out, which simlarly 
reports on the difficulty of explaining some of the conditions 
especially when some are wrong ;-)

 https://groups.google.com/forum/#!topic/git-users/27_FxIV_100


--
Philip