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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 23, 2019, 20:47 UTC
Message-ID: <20190123204721.GB34357@google.com>
In-Reply-To: <20190123202156.GA11293@hank.intra.tgummerer.com>

Thomas Gummerer wrote:

> On 01/22, Jonathan Nieder wrote:

Show 8 quoted lines

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

A patch on top sounds good.

[...]

Show 17 quoted lines

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

Yes, if we have no plan for flipping the default later, then I would prefer to eliminate the config option. Scripts very frequently use human-facing commands like "git checkout" when they want the command to produce (unparsable) friendly output to show to humans, and I don't think we've provided a good alternative for that use case.

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

I would really like this, so I might write a series for it. Please don't wait for me, though --- feel free to send any patches you're thinking about and we can work together or I can just appreciate your work. ;-)

Sincerely, Jonathan