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

From: Boaz Harrosh <bharrosh@panasas.com>
Date: Jun 24, 2008, 17:11 UTC
Message-ID: <48612ABE.6000104@panasas.com>
In-Reply-To: <willow-jeske-01l5cKsCFEDjC=91MX>

David Jeske wrote:

Show 18 quoted lines

> 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

Show 5 quoted lines

> 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