From: "Atsushi Nakagawa" <atnak@xxxxxxxxx>
Kevin Bracey <kevin@xxxxxxxxx> wrote:
On 01/06/2014 07:26, Atsushi Nakagawa wrote:
> Kevin Bracey <kevin@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html