Re: why is git destructive by default? (i suggest it not be!)

[Boaz Harrosh <bharrosh@panasas.com>]

David Jeske wrote:
> As a new user, I'm finding git difficult to trust, because there are operations
> which are destructive by default and capable of inadvertently throwing hours or
> days of work into the bit bucket.
> 
> More problematic, those commands have no discernible pattern that shows their
> danger, and they need to be used to do typical everyday things. I'm starting to
> feel like I need to use another source control system on top of the git
> repository in case I make a mistake.  My philosophy is simple, I never never
> never want to throw away changes, you shouldn't either. Disks are cheaper than
> programmer hours. I can understand wanting to keep things tidy, so I can
> understand ways to correct the 'easily visible changes', and also avoid pushing
> them to other trees, but I don't understand why git needs to delete things.
> 
> For example, the following commands seem capable of totally destroying hours or
> days of work. Some of them need to be used regularly to do everyday things, and
> there is no pattern among them spelling out danger.
> 
> git reset --hard          : if another branch name hasn't been created

git reset --hard is special see below

> git rebase
> git branch -D <branch>    : if branch hasn't been merged
> git branch -f <new>       : if new exists and hasn't been merged
> git branch -m <old> <new> : if new exists and hasn't been merged
> 
The rest of the commands are recoverable from the log as people said
but "git reset --hard" is not and should be *fixed*!

I use git reset --hard in to separate and distinct functions.
One - to move current branch head around from place to place.
Two - Throw away work I've edited

It has happened to me more then once that I wanted the first
and also got the second as an un-warned bonus, to the dismay 
of my bosses. (What do I care if I need to write all this code
again)

I would like git-reset --hard to refuse if a git-diff HEAD
(both staged and unstaged) is not empty. with a -f / -n logic
like git-clean. (like git-clean none default config file override)

Now I know that the first usage above could be done with
git-branch -f that_branch the_other_branch. But that can
not be preformed on the current branch and local changes
are not lost.

Lots of other potentially destructive git-commands check for local
changes and refuse to operate. To remedy them git-reset --hard
is recommended. I would prefer if there was a git-reset --clean -f/-n
for the first case and git reset --hard only for the second usage
case.

My $0.017
Boaz