{"thread":{"id":"28438","subject":"Worktree vs. working copy","startedAt":"2011-09-20T07:50:08Z","lastAt":"2011-09-20T21:45:40Z","messageCount":7,"participants":["Carlos Martín Nieto","Michael Haggerty","Nguyen Thai Ngoc Duy","Ramkumar Ramachandra","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"175838","messageId":"1316505022.13996.12.camel@bee.lab.cmartin.tk","threadId":"28438","inReplyTo":null,"subject":"Worktree vs. working copy","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-20T07:50:08Z","receivedAt":"2011-09-20T07:50:08Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"Hello,\n\nI've noticed that in some places in git.git, the term 'working copy' is\nused. Mostly it's in git-cvsserver which I guess it's fine, but the\ngit-config man page talks about the 'working copy' in three places.\n\n    $ git grep 'worktree' | wc -l\n    412\n    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l\n    32\n\nMost of the references to a 'working copy' are in Git.pm, and the\ngit-gui glossary treats them as the same thing.\n\nIs there some sort of official position, or rough agreement that we\nshould use woktree instead of working copy? The latter term IMHO implies\na centralised system, where an user gets a copy.\n\n   cmn\n"},{"id":"175852","messageId":"4E786D7A.8020503@alum.mit.edu","threadId":"28438","inReplyTo":"1316505022.13996.12.camel@bee.lab.cmartin.tk","subject":"Re: Worktree vs. working copy","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-09-20T10:39:54Z","receivedAt":"2011-09-20T10:39:54Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:\n> I've noticed that in some places in git.git, the term 'working copy' is\n> used. Mostly it's in git-cvsserver which I guess it's fine, but the\n> git-config man page talks about the 'working copy' in three places.\n> \n>     $ git grep 'worktree' | wc -l\n>     412\n>     $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l\n>     32\n\nPlease note that the string \"worktree\" mostly appears in code\n(presumably as variable names) and in the names of options.  In text,\n\"working tree\" is far more common than either:\n\n$ git grep -i 'worktree' -- '*.txt' | wc -l\n50\n$ git grep -i 'working copy' -- '*.txt' | wc -l\n6\n$ git grep -i 'working tree' -- '*.txt' | wc -l\n330\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"175854","messageId":"CACsJy8AtO3EhgscLVjmqzyRAo+Q=d7ABg0VaJ4N7oqCpmKVzuA@mail.gmail.com","threadId":"28438","inReplyTo":"4E786D7A.8020503@alum.mit.edu","subject":"Re: Worktree vs. working copy","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-09-20T10:48:58Z","receivedAt":"2011-09-20T10:48:58Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Sep 20, 2011 at 8:39 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:\n> On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:\n>> I've noticed that in some places in git.git, the term 'working copy' is\n>> used. Mostly it's in git-cvsserver which I guess it's fine, but the\n>> git-config man page talks about the 'working copy' in three places.\n>>\n>>     $ git grep 'worktree' | wc -l\n>>     412\n>>     $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l\n>>     32\n>\n> Please note that the string \"worktree\" mostly appears in code\n> (presumably as variable names) and in the names of options.  In text,\n> \"working tree\" is far more common..\n\nAnd probably the oldest. It was mentioned in the first version of git\nglossary back in 2005, da13981, [PATCH] Add GIT glossary.\n-- \nDuy\n"},{"id":"175855","messageId":"CALkWK0mHQZEPKk3Dy3RSp70thcsw3x6RSvUxTuPVzzRjgsM8-A@mail.gmail.com","threadId":"28438","inReplyTo":"1316505022.13996.12.camel@bee.lab.cmartin.tk","subject":"Re: Worktree vs. working copy","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-09-20T10:56:08Z","receivedAt":"2011-09-20T10:56:08Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Carlos,\n\nCarlos Martín Nieto writes:\n> [...]\n>    $ git grep 'worktree' | wc -l\n>    412\n>    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l\n>    32\n> [...]\n\nYou might like to refer to a related discussion [1].\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083\n\n-- Ram\n"},{"id":"175879","messageId":"7vhb476ned.fsf@alter.siamese.dyndns.org","threadId":"28438","inReplyTo":"CALkWK0mHQZEPKk3Dy3RSp70thcsw3x6RSvUxTuPVzzRjgsM8-A@mail.gmail.com","subject":"Re: Worktree vs. working copy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-20T19:10:02Z","receivedAt":"2011-09-20T19:10:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> Hi Carlos,\n>\n> Carlos Martín Nieto writes:\n>> [...]\n>>    $ git grep 'worktree' | wc -l\n>>    412\n>>    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l\n>>    32\n>> [...]\n>\n> You might like to refer to a related discussion [1].\n>\n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083\n\nSorry, I do not see \"working tree\" discussion there. The discussion on\nthat quoted thread was about remote-tracking branches, no?\n\nHistorically, we used to say \"working tree\" and \"worktree\" more or less\ninterchangeably, and over time we tried to update the documentation to use\n\"working tree\" consistently, even though the latter is still seen in\nplaces like \"GIT_WORK_TREE\" environment variable (which will _not_\nchange).\n\nBut as far as I recall, we have never referred to the working tree\ncontrolled by a git repository as \"working copy\".\n"},{"id":"175894","messageId":"1316550362.8701.32.camel@centaur.lab.cmartin.tk","threadId":"28438","inReplyTo":"7vhb476ned.fsf@alter.siamese.dyndns.org","subject":"Re: Worktree vs. working copy","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-09-20T20:25:57Z","receivedAt":"2011-09-20T20:25:57Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Tue, 2011-09-20 at 12:10 -0700, Junio C Hamano wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n> \n> > Hi Carlos,\n> >\n> > Carlos Martín Nieto writes:\n> >> [...]\n> >>    $ git grep 'worktree' | wc -l\n> >>    412\n> >>    $ git grep 'working copy' | grep -v ^git-cvsserver |  wc -l\n> >>    32\n> >> [...]\n> >\n> > You might like to refer to a related discussion [1].\n> >\n> > [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083\n> \n> Sorry, I do not see \"working tree\" discussion there. The discussion on\n> that quoted thread was about remote-tracking branches, no?\n> \n> Historically, we used to say \"working tree\" and \"worktree\" more or less\n> interchangeably, and over time we tried to update the documentation to use\n> \"working tree\" consistently, even though the latter is still seen in\n> places like \"GIT_WORK_TREE\" environment variable (which will _not_\n> change).\n> \n> But as far as I recall, we have never referred to the working tree\n> controlled by a git repository as \"working copy\".\n\nThe config man page has three mentions, diff-lib.c has one,\nmerge-recursive.c three and perl/Git.pm nine.\n\nThis patch covers the documentation and C code. I'll move the perl code\nover if you want, but I'm not sure how well maintained or relevant that\npart of the codebase is.\n\n--- 8< ---\n\nSubject: [PATCH] Remove 'working copy' from the documentation and C code\n\nThe git term is 'working tree', so replace the most public references\nto 'working copy'.\n\nSigned-off-by: Carlos Martín Nieto <cmn@elego.de>\n---\n Documentation/config.txt  |    6 +++---\n Documentation/git-svn.txt |    2 +-\n diff-lib.c                |    2 +-\n merge-recursive.c         |    2 +-\n 4 files changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6b93777..c3f22f3 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -147,7 +147,7 @@ advice.*::\n \n core.fileMode::\n \tIf false, the executable bit differences between the index and\n-\tthe working copy are ignored; useful on broken filesystems like FAT.\n+\tthe working tree are ignored; useful on broken filesystems like FAT.\n \tSee linkgit:git-update-index[1].\n +\n The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]\n@@ -179,7 +179,7 @@ is created.\n \n core.trustctime::\n \tIf false, the ctime differences between the index and the\n-\tworking copy are ignored; useful when the inode change time\n+\tworking tree are ignored; useful when the inode change time\n \tis regularly modified by something outside Git (file system\n \tcrawlers and some backup systems).\n \tSee linkgit:git-update-index[1]. True by default.\n@@ -292,7 +292,7 @@ core.ignoreStat::\n \tIf true, commands which modify both the working tree and the index\n \twill mark the updated paths with the \"assume unchanged\" bit in the\n \tindex. These marked files are then assumed to stay unchanged in the\n-\tworking copy, until you\tmark them otherwise manually - Git will not\n+\tworking tree, until you mark them otherwise manually - Git will not\n \tdetect the file changes\tby lstat() calls. This is useful on systems\n \twhere those are very slow, such as Microsoft Windows.\n \tSee linkgit:git-update-index[1].\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex 713e523..4ba6f61 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -297,7 +297,7 @@ Any other arguments are passed directly to 'git log'\n        Show what revision and author last modified each line of a file. The\n        output of this mode is format-compatible with the output of\n        `svn blame' by default. Like the SVN blame command,\n-       local uncommitted changes in the working copy are ignored;\n+       local uncommitted changes in the working tree are ignored;\n        the version of the file in the HEAD revision is annotated. Unknown\n        arguments are passed directly to 'git blame'.\n +\ndiff --git a/diff-lib.c b/diff-lib.c\nindex 9c29293..c7d33d7 100644\n--- a/diff-lib.c\n+++ b/diff-lib.c\n@@ -289,7 +289,7 @@ static void show_new_file(struct rev_info *revs,\n \n \t/*\n \t * New file in the index: it might actually be different in\n-\t * the working copy.\n+\t * the working tree.\n \t */\n \tif (get_stat_data(new, &sha1, &mode, cached, match_missing,\n \t    &dirty_submodule, &revs->diffopt) < 0)\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex db9ba19..0c9f77e 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -337,7 +337,7 @@ static void make_room_for_directories_of_df_conflicts(struct merge_options *o,\n \t\t\t\t\t\t      struct string_list *entries)\n {\n \t/* If there are D/F conflicts, and the paths currently exist\n-\t * in the working copy as a file, we want to remove them to\n+\t * in the working tree as a file, we want to remove them to\n \t * make room for the corresponding directory.  Such paths will\n \t * later be processed in process_df_entry() at the end.  If\n \t * the corresponding directory ends up being removed by the\n-- \n1.7.5.2.354.g349bf\n\n\n"},{"id":"175941","messageId":"7vliti2hoq.fsf@alter.siamese.dyndns.org","threadId":"28438","inReplyTo":"1316550362.8701.32.camel@centaur.lab.cmartin.tk","subject":"Re: Worktree vs. working copy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-09-20T21:45:40Z","receivedAt":"2011-09-20T21:45:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carlos Martín Nieto <cmn@elego.de> writes:\n\n> Subject: [PATCH] Remove 'working copy' from the documentation and C code\n>\n> The git term is 'working tree', so replace the most public references\n> to 'working copy'.\n>\n> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>\n\nThanks.\n\n\"working tree\" is a term used to collectively call the whole, and I think\nall the places in your patch read better with \"working tree\".\n\nPeople with background from other systems refer to one particular file in\nthe working tree as \"working copy\", I think, but...\n\n>  core.fileMode::\n>  \tIf false, the executable bit differences between the index and\n> -\tthe working copy are ignored; useful on broken filesystems like FAT.\n> +\tthe working tree are ignored; useful on broken filesystems like FAT.\n\n... this compares \"the index and the working tree\", meaning each path in\nthe index and the corresponding file in the working tree (both are taken\nas a _collection_), so this rewrite makes perfect sense.  The same for\nthe description for trustctime.\n\n> @@ -292,7 +292,7 @@ core.ignoreStat::\n>  \tIf true, commands which modify both the working tree and the index\n>  \twill mark the updated paths with the \"assume unchanged\" bit in the\n>  \tindex. These marked files are then assumed to stay unchanged in the\n> -\tworking copy, until you\tmark them otherwise manually - Git will not\n> +\tworking tree, until you mark them otherwise manually - Git will not\n\nThis again is \"paths in the\" working tree, and the term is used as a\ncollection (good).  The same for \"git-svn\" manpage.\n\n> diff --git a/diff-lib.c b/diff-lib.c\n> index 9c29293..c7d33d7 100644\n> --- a/diff-lib.c\n> +++ b/diff-lib.c\n> @@ -289,7 +289,7 @@ static void show_new_file(struct rev_info *revs,\n>  \n>  \t/*\n>  \t * New file in the index: it might actually be different in\n> -\t * the working copy.\n> +\t * the working tree.\n>  \t */\n\nWe are looking at one path, and wondering if it is different \"in the\"\nworking tree---again used as a collection (it would have said \"it might\nactually be different from the working copy\" if it referred to an instance\nin the collection). The same for the comment in merge-recursive.c.\n"}]}