Hi,
Thomas Gummerer wrote:
> Currently 'git checkout' is defined as an overlay operation, which
> means that if in 'git checkout <tree-ish> -- [<pathspec>]' we have an
> entry in the index that matches <pathspec>, but that doesn't exist in
> <tree-ish>, that entry will not be removed from the index or the
> working tree.
>
> Introduce a new --{,no-}overlay option, which allows using 'git
> checkout' in non-overlay mode, thus removing files from the working
> tree if they do not exist in <tree-ish> but match <pathspec>.
This patch just hit my workstation. Some initial thoughts:
I had no idea what --overlay would mean and am still not clear on it.
Is this analogous to "git add --ignore-removal"? If so, can we just
call it --ignore-removal?
Thank you thank you thank you for working on this. I run into this
all the time and am super excited about the "default to
--no-ignore-removal" future.
I'm nervous about the config with no associated warning or plan for
phasing it out. It means that scripts using "git checkout" don't
get a consistent behavior unless they explicitly pass this option,
which didn't exist in older versions of Git --- in other words,
scripts have no real good option. Can we plan a transition to
making --no-ignore-removal the default, in multiple steps? For
example:
1. First introduce the commandline option, as in this series
2. Next, change the default to warn whenever the difference would
matter, printing a hint about how to configure to explicitly
request the old or new behavior.
3. After a release or two has passed so people get a chance
to update their scripts, flip the default.
4. Finally, remove the warning.
5. Warn whenver the difference would matter when a user has
requested the old behavior through config, in preparation
for removing the config.
6. Remove the config.
Steps 5 and 6 are optional but might be nice.
What do you think?
Thanks,
Jonathan
