From: Phillip Wood Date: Wed, 01 May 2019 14:58:28 GMT Subject: Re: [PATCH 0/2] read-tree: improve untracked file support Message-ID: In-Reply-To: On 01/05/2019 11:31, Duy Nguyen wrote: > On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote: >> >> From: Phillip Wood >> >> These two patches teach read-tree how to avoid overwriting untracked >> files when doing '--reset -u' and also how to respect all of git's >> standard excludes files. I'd like to see the porcelain commands stop >> overwriting untracked files, this is a first step on the way. I'm not >> sure if we want to add options to the porcelain commands to protect >> untracked files or just change their behavior and add an option to >> override that. I'm leaning towards the latter but I'd be interested to >> hear what others think. > > For new commands like git-restore, it's definitely a good thing to not > overwrite untracked files. I agree, unfortunately this series does not help with git-restore, only git-switch. For restore on an index without conflicts I think it could just use the pathspec in struct unpack_trees_options and set opts.rest = UNPACK_RESET_PROTECT_UNTRACKED but that does not help if we want to handle conflicted paths differently to non-conflicted paths. > For existing commands I guess we have to go > over them one by one. For "git reset --hard", it should really just > overwrite whatever needed to get back to the known good state. "git > checkout -f" , not so sure (seems weird that we need force-level-two > option to override the protection provided by -f, if we change default > behavior) I think it's fine for "checkout -f" to overwrite untracked files (and if "switch --discard-changes" does not then there is no pressing need to add such a mode to checkout), --force is a good name for an option that nukes everything that gets in it's way. For "reset --hard" I'm not so sure, if I have changes to an untracked file I don't wont them overwritten by default. There is no porcelain equivalent to "read-tree --reset --protect-untracked -u" and I was hoping "reset --hard" may become that porcelain equivalent with a new --force or --overwrite-untracked option. For the various "foo --abort" some (most?) are using "reset --merge" which I think declines to overwrite untracked files but rebase uses "reset --hard" which I'd like to change to protect untracked files in the same way that rebase does for the initial checkout and when picking commits. I haven't thought about stash. Best Wishes Phillip