Boaz Harrosh wrote: > 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. Sorry git-reset --clean -f/-n for removing local changes git reset --hard for moving HEAD on a clean tree only > > 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