Re: Reset by checkout?

From: Atsushi Nakagawa <atnak@chejz.com>
Date: Jun 7, 2014, 04:54 UTC
Message-ID: <20140607135439.7893.B013761@chejz.com>
In-Reply-To: <538AE814.2010407@bracey.fi>

Kevin Bracey <kevin@bracey.fi> wrote:

Show 20 quoted lines

> 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.

Show 9 quoted lines

> --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
<atnak@chejz.com>
Changes are made when there is inconvenience.