Re: [PATCH 0/2] read-tree: improve untracked file support

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

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