Carlos Martín Nieto <cmn@xxxxxxxx> writes: > Subject: [PATCH] Remove 'working copy' from the documentation and C code > > The git term is 'working tree', so replace the most public references > to 'working copy'. > > Signed-off-by: Carlos Martín Nieto <cmn@xxxxxxxx> Thanks. "working tree" is a term used to collectively call the whole, and I think all the places in your patch read better with "working tree". People with background from other systems refer to one particular file in the working tree as "working copy", I think, but... > core.fileMode:: > If false, the executable bit differences between the index and > - the working copy are ignored; useful on broken filesystems like FAT. > + the working tree are ignored; useful on broken filesystems like FAT. ... this compares "the index and the working tree", meaning each path in the index and the corresponding file in the working tree (both are taken as a _collection_), so this rewrite makes perfect sense. The same for the description for trustctime. > @@ -292,7 +292,7 @@ core.ignoreStat:: > If true, commands which modify both the working tree and the index > will mark the updated paths with the "assume unchanged" bit in the > index. These marked files are then assumed to stay unchanged in the > - working copy, until you mark them otherwise manually - Git will not > + working tree, until you mark them otherwise manually - Git will not This again is "paths in the" working tree, and the term is used as a collection (good). The same for "git-svn" manpage. > diff --git a/diff-lib.c b/diff-lib.c > index 9c29293..c7d33d7 100644 > --- a/diff-lib.c > +++ b/diff-lib.c > @@ -289,7 +289,7 @@ static void show_new_file(struct rev_info *revs, > > /* > * New file in the index: it might actually be different in > - * the working copy. > + * the working tree. > */ We are looking at one path, and wondering if it is different "in the" working tree---again used as a collection (it would have said "it might actually be different from the working copy" if it referred to an instance in the collection). The same for the comment in merge-recursive.c. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html