Re: [PATCH 0/2] read-tree: improve untracked file support
- Date: Tue, 7 May 2019 18:02:14 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: [PATCH 0/2] read-tree: improve untracked file support
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)