On Tue, May 7, 2019 at 5:02 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > My (biased, obviously) view is that "git reset --hard" is very > > dangerous and I'm not trying to change that, especially when its > > behavior has been like this since forever and I'm sure it's used in > > scripts. > > > > Instead "git restore" should be used when you need "git reset --hard > > HEAD", the most often use case. And since it's new, changing default > > behavior is not a problem. Which brings us back to git-restore :) > > Does restore clean up the branch state like reset? It's tricky because > you only want to do that if there is no pathspec (or the pathspec is :/ > or equivalent - I can't remember if restore always requires paths or not) Nope. git-restore cares about files, not branches. Yes git-restore always requires paths, just in case people type "git restore" and expect to see help usage or something. > > But either way, git-restore or git-reset, I still don't see why > > untracked files are more valuable in this case than tracked ones to > > change the default. > > My issue is that is easy to see what changes you're going to lose in > tracked files by running diff. For untracked files diff just says a new > file will be created, it ignores the current contents as the path is in > the index so it is easy to overwrite changes without realizing. There's > also a philosophical point that git should not be stomping on paths that > it is not tracking though that's a bit moot if a path is tracked in one > revision but not another. Ah good point about diff. If only we had "git reset --dry-run" (that shows the diff, including untracked files; or perhaps --diff would be a better name for that imaginary option) -- Duy
