Re: [PATCH v3 7/8] checkout: introduce --{,no-}overlay option

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 22, 2019, 23:53 UTC
Message-ID: <20190122235313.GA199923@google.com>
In-Reply-To: <20190108215225.3077-8-t.gummerer@gmail.com>

Hi,

Thomas Gummerer wrote:

Show 9 quoted lines

> 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