Hi,
On Sat, Mar 9, 2019 at 9:29 AM Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote:
>
> 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>>.
I think this is good, but maybe also add:
In contrast, no-overlay mode will also delete files not present in
the source, similar to 'rsync --delete'
?
> +
> [[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
