Re: What's cooking in git.git (Mar 2019, #01; Wed, 6)

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

On 03/07, Duy Nguyen wrote:
> On Thu, Mar 7, 2019 at 7:34 PM Philip Oakley <philipoakley@iee.org> wrote:
> >
> > On 06/03/2019 09:44, Duy Nguyen wrote:
> > > On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano <gitster@pobox.com> wrote:
> > >> * tg/checkout-no-overlay (2019-02-04) 9 commits
> > >>    (merged to 'next' on 2019-02-04 at 9968bcf4fb)
> > >>   + revert "checkout: introduce checkout.overlayMode config"
> > >>    (merged to 'next' on 2019-01-18 at 1e2a79ba5c)
> > >>   + checkout: introduce checkout.overlayMode config
> > >>   + checkout: introduce --{,no-}overlay option
> > >>   + checkout: factor out mark_cache_entry_for_checkout function
> > >>   + checkout: clarify comment
> > >>   + read-cache: add invalidate parameter to remove_marked_cache_entries
> > >>   + entry: support CE_WT_REMOVE flag in checkout_entry
> > >>   + entry: factor out unlink_entry function
> > >>   + move worktree tests to t24*
> > >>
> > >>   "git checkout --no-overlay" can be used to trigger a new mode of
> > >>   checking out paths out of the tree-ish, that allows paths that
> > >>   match the pathspec that are in the current index and working tree
> > >>   and are not in the tree-ish.
> > >>
> > >>   Will hold.
> > >>   Waiting for "restore-files" & "switch-branches" pair.
> > >>   cf. <20190205204208.GC6085@hank.intra.tgummerer.com>
> > > If it's ready for master, I'd love to see it merged. Either that or
> > > topic is rebased on 'master'. There are separate checkout changes in
> > > 'master' (mine, sadly), and because switch/restore moves lots of code
> > > around, I need to create a merge of this topic and master as the base,
> > > or you'll get horrible conflicts.
> > >
> > > I should send switch/restore again soon. There are still a few
> > > unaddressed concerns for git-restore since last time. Probably time to
> > > refresh those discussions.
> >
> > Just catching up on back emails:
> >
> > The one point I noted is that "Overlay" is a new magic term without any
> > explanation within the _documentation_.
> >
> > It would appear worth it to also add something (follow up patch?) to the
> > e.g. git glossary to clarify how overlay differs, or is similar to, the
> > different merge and reset modes.
> 
> I think Jonathan questions the name "overlay" too. Since this is
> similar to "cp -R" mode, another suggestion is --copy-mode.

That would leave the negative form as --no-copy-mode, which almost
sounds like we wouldn't copy anything.  I think that would be more
confusing that [no ]overlay mode.

I'd be fine in general with changing the name, if there is a consensus
for a different and better name, but I also think overlay is
reasonable, so I'd rather leave pushing for a different name to
someone else that has strong opinions about it.

Philip, do you think something like this would help?  Not sure if it
should be called overlay_mode in the glossary, rather than just
overlay?

--- >8 ---
Subject: [PATCH] glossary: add definition for overlay

Add a definition for what overlay means in the context of git, to
clarify the recently introduced overlay-mode in git checkout.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
 Documentation/glossary-content.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 023ca95e7c..70e6477a9f 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -287,6 +287,11 @@ This commit is referred to as a "merge commit", or sometimes just a
 	origin/name-of-upstream-branch, which you can see using
 	`git branch -r`.
 
+[[def_overlay]]overlay::
+	Only update and add files to the working directory, but don't
+	delete them, similar to how 'cp -R' works.  This is the
+	default in a <<def_checkout,checkout>>.
+
 [[def_pack]]pack::
 	A set of objects which have been compressed into one file (to save space
 	or to transmit them efficiently).
-- 
2.20.1.495.gaa96b0ce6b