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

[Duy Nguyen <pclouds@gmail.com>]

On Tue, May 7, 2019 at 5:02 PM Phillip Wood <phillip.wood123@gmail.com> 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