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

From: Thomas Gummerer <t.gummerer@gmail.com>
Date: Dec 11, 2018, 22:07 UTC
Message-ID: <20181211220752.GR4883@hank.intra.tgummerer.com>
In-Reply-To: <xmqqzhtclq22.fsf@gitster-ct.c.googlers.com>

On 12/11, Junio C Hamano wrote:

Show 15 quoted lines

> Elijah Newren <newren@gmail.com> writes:
> 
> >> 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.

I wonder whether it's worth introducing a config option for this, so people could use this new mode by default if they wanted to, without having to type the extra argument?

'git checkout' is a plumbing command, but I see that some of the shell scripts in git.git are using it. Though they are only using it in the checkout branch mode, rather than the checkout paths mode.

Show 12 quoted lines

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