threads / discuss / 28438

Worktree vs. working copy

Subject: Worktree vs. working copy

## tl;dr

7 messages between Sep 20, 2011 and Sep 20, 2011.

replies: 6people: 5as markdown or json

Carlos Martín Nieto· Sep 20, 2011, 07:50 UTC · lore
Hello,

I've noticed that in some places in git.git, the term 'working copy' is used. Mostly it's in git-cvsserver which I guess it's fine, but the git-config man page talks about the 'working copy' in three places.

    $ git grep 'worktree' | wc -l
    412
    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l
    32

Most of the references to a 'working copy' are in Git.pm, and the git-gui glossary treats them as the same thing.

Is there some sort of official position, or rough agreement that we should use woktree instead of working copy? The latter term IMHO implies a centralised system, where an user gets a copy.

   cmn
Michael Haggerty· Sep 20, 2011, 10:39 UTC · re: Carlos Martín Nieto · lore

Re: Worktree vs. working copy

On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:
Show 8 quoted lines
> I've noticed that in some places in git.git, the term 'working copy' is
> used. Mostly it's in git-cvsserver which I guess it's fine, but the
> git-config man page talks about the 'working copy' in three places.
> 
>     $ git grep 'worktree' | wc -l
>     412
>     $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l
>     32

Please note that the string "worktree" mostly appears in code (presumably as variable names) and in the names of options. In text, "working tree" is far more common than either:

$ git grep -i 'worktree' -- '*.txt' | wc -l 50 $ git grep -i 'working copy' -- '*.txt' | wc -l 6 $ git grep -i 'working tree' -- '*.txt' | wc -l 330

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Nguyen Thai Ngoc Duy· Sep 20, 2011, 10:48 UTC · re: Michael Haggerty · lore

Re: Worktree vs. working copy

On Tue, Sep 20, 2011 at 8:39 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 13 quoted lines
> On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:
>> I've noticed that in some places in git.git, the term 'working copy' is
>> used. Mostly it's in git-cvsserver which I guess it's fine, but the
>> git-config man page talks about the 'working copy' in three places.
>>
>>     $ git grep 'worktree' | wc -l
>>     412
>>     $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l
>>     32
>
> Please note that the string "worktree" mostly appears in code
> (presumably as variable names) and in the names of options.  In text,
> "working tree" is far more common..

And probably the oldest. It was mentioned in the first version of git glossary back in 2005, da13981, [PATCH] Add GIT glossary.

-- 
Duy
Ramkumar Ramachandra· Sep 20, 2011, 10:56 UTC · re: Carlos Martín Nieto · lore

Re: Worktree vs. working copy

Hi Carlos,
Carlos Martín Nieto writes:
Show 6 quoted lines
> [...]
>    $ git grep 'worktree' | wc -l
>    412
>    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l
>    32
> [...]
You might like to refer to a related discussion [1].
[1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
-- Ram
Junio C Hamano· Sep 20, 2011, 19:10 UTC · re: Ramkumar Ramachandra · lore

Re: Worktree vs. working copy

Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 13 quoted lines
> Hi Carlos,
>
> Carlos Martín Nieto writes:
>> [...]
>>    $ git grep 'worktree' | wc -l
>>    412
>>    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l
>>    32
>> [...]
>
> You might like to refer to a related discussion [1].
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083

Sorry, I do not see "working tree" discussion there. The discussion on that quoted thread was about remote-tracking branches, no?

Historically, we used to say "working tree" and "worktree" more or less interchangeably, and over time we tried to update the documentation to use "working tree" consistently, even though the latter is still seen in places like "GIT_WORK_TREE" environment variable (which will _not_ change).

But as far as I recall, we have never referred to the working tree controlled by a git repository as "working copy".

Carlos Martín Nieto· Sep 20, 2011, 20:25 UTC · re: Junio C Hamano · lore

Re: Worktree vs. working copy

On Tue, 2011-09-20 at 12:10 -0700, Junio C Hamano wrote:
Show 27 quoted lines
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
> 
> > Hi Carlos,
> >
> > Carlos Martín Nieto writes:
> >> [...]
> >>    $ git grep 'worktree' | wc -l
> >>    412
> >>    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l
> >>    32
> >> [...]
> >
> > You might like to refer to a related discussion [1].
> >
> > [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
> 
> Sorry, I do not see "working tree" discussion there. The discussion on
> that quoted thread was about remote-tracking branches, no?
> 
> Historically, we used to say "working tree" and "worktree" more or less
> interchangeably, and over time we tried to update the documentation to use
> "working tree" consistently, even though the latter is still seen in
> places like "GIT_WORK_TREE" environment variable (which will _not_
> change).
> 
> But as far as I recall, we have never referred to the working tree
> controlled by a git repository as "working copy".

The config man page has three mentions, diff-lib.c has one, merge-recursive.c three and perl/Git.pm nine.

This patch covers the documentation and C code. I'll move the perl code over if you want, but I'm not sure how well maintained or relevant that part of the codebase is.

--- 8< ---
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@elego.de>
---
 Documentation/config.txt  |    6 +++---
 Documentation/git-svn.txt |    2 +-
 diff-lib.c                |    2 +-
 merge-recursive.c         |    2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6b93777..c3f22f3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -147,7 +147,7 @@ advice.*::
 
 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.
 	See linkgit:git-update-index[1].
 +
 The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
@@ -179,7 +179,7 @@ is created.
 
 core.trustctime::
 	If false, the ctime differences between the index and the
-	working copy are ignored; useful when the inode change time
+	working tree are ignored; useful when the inode change time
 	is regularly modified by something outside Git (file system
 	crawlers and some backup systems).
 	See linkgit:git-update-index[1]. True by default.
@@ -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
 	detect the file changes	by lstat() calls. This is useful on systems
 	where those are very slow, such as Microsoft Windows.
 	See linkgit:git-update-index[1].
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 713e523..4ba6f61 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -297,7 +297,7 @@ Any other arguments are passed directly to 'git log'
        Show what revision and author last modified each line of a file. The
        output of this mode is format-compatible with the output of
        `svn blame' by default. Like the SVN blame command,
-       local uncommitted changes in the working copy are ignored;
+       local uncommitted changes in the working tree are ignored;
        the version of the file in the HEAD revision is annotated. Unknown
        arguments are passed directly to 'git blame'.
 +
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.
 	 */
 	if (get_stat_data(new, &sha1, &mode, cached, match_missing,
 	    &dirty_submodule, &revs->diffopt) < 0)
diff --git a/merge-recursive.c b/merge-recursive.c
index db9ba19..0c9f77e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -337,7 +337,7 @@ static void make_room_for_directories_of_df_conflicts(struct merge_options *o,
 						      struct string_list *entries)
 {
 	/* If there are D/F conflicts, and the paths currently exist
-	 * in the working copy as a file, we want to remove them to
+	 * in the working tree as a file, we want to remove them to
 	 * make room for the corresponding directory.  Such paths will
 	 * later be processed in process_df_entry() at the end.  If
 	 * the corresponding directory ends up being removed by the
-- 
1.7.5.2.354.g349bf
Junio C Hamano· Sep 20, 2011, 21:45 UTC · re: Carlos Martín Nieto · lore

Re: Worktree vs. working copy

Carlos Martín Nieto <cmn@elego.de> writes:
Show 6 quoted lines
> 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@elego.de>
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.

Show 6 quoted lines
> @@ -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.

Show 11 quoted lines
> 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.

← back to recent threads