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