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

[Thomas Gummerer <t.gummerer@gmail.com>]

On 01/22, Jonathan Nieder wrote:
> 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?

Yes, it seems like they are very similar.  I'm happy to rename the
option.  The topic seems to have made it to 'next' already, so I'll
submit the patches on top, unless reverting the topic out of next and
replacing it is preferred?

> 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:

As Junio mentioned, the plan was to just have this mode default when
we introduce the new checkout-paths command.

As checkout is a porcelain command, I had hoped it would be okay to
also have this as a configuration option, for the time before
'checkout-paths' exists and while I'm getting used to actually typing
'checkout-paths' instead of 'checkout'.  However I get that there may
be scripts that are using git checkout, and expect the previous
behaviour, so I'm also okay with dropping the config option for now.

If we still want to make this the default even after 'checkout-paths'
exists, the plan you outline below sounds good to me, though maybe we
can make the "flip the default" step once we decide to release git
3.0.

>  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