On 03/07, Duy Nguyen wrote:
> On Thu, Mar 7, 2019 at 7:34 PM Philip Oakley <philipoakley@xxxxxxx> wrote:
> >
> > On 06/03/2019 09:44, Duy Nguyen wrote:
> > > On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxx>
> > > 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@xxxxxxxxx>
---
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
