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