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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 11, 2018, 03:07 UTC
Message-ID: <xmqqzhtclq22.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CABPp-BEk+7n2wcbjETishqnMBs5DGrTEvD7gahLtEj5bZ2AYvA@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 11 quoted lines

>> Note that 'git checkout -p <tree-ish> -- [<pathspec>]' already works
>> this way, so no changes are needed for the patch mode.  We disallow
>> 'git checkout --overlay -p' to avoid confusing users who would expect
>> to be able to force overlay mode in 'git checkout -p' this way.
>
> Whoa...that's interesting.  To me, that argues even further that the
> traditional checkout behavior was wrong all along and the choice of
> --overlay vs. --no-overlay in the original implementation was a total
> oversight.  I'm really tempted to say that --no-overlay should just be
> the default in checkout too...but maybe that's too high a hill to
> climb, at least for now.

You are exhibiting a typical reaction to a shiny new toy.

The original "checkout paths out of the trees and/or the index to recover what was lost" is modeled after "cp -R .../else/where .", which is an overlay operation, and you wouldn't imagine complaining that "cp -R" is wrong not to remove things in the target, to be equivalent to "rm -fr where && cp -R .../else/where .".

Each has its own uses. We just didn't have the other half of the pair.

If anything, I would consider "checkout -p" that does not do overlay is a bug that needs to be fixed.