Re: [PATCH v3] glossary: add definition for overlay

From: Junio C Hamano <gitster@pobox.com>
To: Philip Oakley <philipoakley@iee.org>
Cc: Thomas Gummerer <t.gummerer@gmail.com>,
	Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH v3] glossary: add definition for overlay
Date: Fri, 22 Mar 2019 13:54:51 +0900	[thread overview]
Message-ID: <xmqqbm23qzj8.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <3d2ad13b-b5de-7e8f-9647-983e964c6303@iee.org> (Philip Oakley's message of "Thu, 21 Mar 2019 14:48:28 +0000")

Philip Oakley <philipoakley@iee.org> writes:

>> of 'cp -R'.  I thought of making the same clarification for 'rsync
>> --delete' as well, however I think with it being explicitly specified
>> for 'cp -R', readers should be able to deduce that we are talking
>> about the destination directory there as well.
> As a historically Windows user, we should ensure that the meaning is
> clear to all without the otherwise helpful *nix command examples.

I do not know about "cp -R", but surely "rsync" is used by Windows
users as well as users of Unix based systems, isn't it?

>> +	Only update and add files to the working directory, but don't
>> +	delete them, similar to how 'cp -R' would update the contents

> perhaps  s/them/any files/

Probably.  The paths that are not deleted are certainly different
set of paths from those that are updated and/or added, so it sounds
like a reasonable thing to do.

>> +	in the destination directory.  This is the default mode in a
>> +	<<def_checkout,checkout>> when checking out files from the
>> +	<<def_index,index>> or a <<def_tree-ish,tree-ish>>.  In
>> +	contrast, no-overlay mode also deletes tracked files not
>
> understanding the past/future distinction is tricky here. Maybe
> 'deletes previously tracked files that are no longer present in the
> new source'.
>
> It's tricky talking about deleting things that are not there.

I am afraid that "previously" may be taken too literally by readers
and misunderstood as paths that had been tracked even once in the
past.  

If you think that is worried too much because we can only delete
what is _currently_ in the index, and any past before what is in the
current index cannot ever affect the outcome, the same reasoning
tells me that the original is clear enough without "previously",
i.e. "tracked ones not present in..." are the ones that are in the
index currently, but the tree that we are taking new contents from
does not have them.

I dunno.

>> +	present in the source, similar to 'rsync --delete'.