{"thread":{"id":"9448","subject":"[PATCH] cvsserver: Fix for work trees","startedAt":"2007-08-09T04:26:10Z","lastAt":"2007-08-09T08:45:07Z","messageCount":3,"participants":["Brian Downing","Junio C Hamano","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"50276","messageId":"1186633570700-git-send-email-bdowning@lavos.net","threadId":"9448","inReplyTo":null,"subject":"[PATCH] cvsserver: Fix for work trees","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-08-09T04:26:10Z","receivedAt":"2007-08-09T04:26:10Z","isPatch":true,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"git-cvsserver used checkout-index internally for commit and annotate.\nSince a work tree is required for this to function now, this was\nbreaking.  Work around this by defining GIT_WORK_TREE=. in the\nappropriate places.\n\nSigned-off-by: Brian Downing <bdowning@lavos.net>\n---\n git-cvsserver.perl |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex ae7d511..13dbd27 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -1196,6 +1196,7 @@ sub req_ci\n     $log->info(\"Lockless commit start, basing commit on '$tmpdir', index file is '$file_index'\");\n \n     $ENV{GIT_DIR} = $state->{CVSROOT} . \"/\";\n+    $ENV{GIT_WORK_TREE} = \".\";\n     $ENV{GIT_INDEX_FILE} = $file_index;\n \n     # Remember where the head was at the beginning.\n@@ -1721,6 +1722,7 @@ sub req_annotate\n     $log->info(\"Temp checkoutdir creation successful, basing annotate session work on '$tmpdir', index file is '$file_index'\");\n \n     $ENV{GIT_DIR} = $state->{CVSROOT} . \"/\";\n+    $ENV{GIT_WORK_TREE} = \".\";\n     $ENV{GIT_INDEX_FILE} = $file_index;\n \n     chdir $tmpdir;\n-- \n1.5.3.GIT\n"},{"id":"50280","messageId":"7v1wedz2er.fsf@assigned-by-dhcp.cox.net","threadId":"9448","inReplyTo":"1186633570700-git-send-email-bdowning@lavos.net","subject":"Re: [PATCH] cvsserver: Fix for work trees","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-09T05:45:48Z","receivedAt":"2007-08-09T05:45:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Hmmmmm....\n\nThis is a good fix to adjust to the new world order introduced\nby Dscho's rewrite of work-tree stuff, where the rules are:\n\n * When GIT_DIR is set and GIT_WORK_TREE is not, GIT_DIR is used\n   to read config file, to figure out core.worktree.  When\n   core.worktree is not set, a complicated algorithm is used to\n   figure out the top of the working tree based on the value of\n   GIT_DIR, and this can sometimes figure out that you are in a\n   subdirectory of the working tree.  In such a case, you are in\n   the working tree, but not necessarily at the top.\n\n * Otherwise, commands that require to have working tree now\n   barf.  Earlier they always and consistently treated that your\n   $cwd is the top of working tree and did not barf.\n\nThis new world order is probably an improvement, and if the\nrules were like this from the beginning, it would have been\nmuch nicer.  However, this _is_ a change of semantics in the\nmiddle of the road, and probably we will see many fallouts like\nthis.  Unfortunate...  I am torn between a cleaner semantics and\nthe short-term pain...\n"},{"id":"50299","messageId":"Pine.LNX.4.64.0708090943340.21857@racer.site","threadId":"9448","inReplyTo":"7v1wedz2er.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] cvsserver: Fix for work trees","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-09T08:45:07Z","receivedAt":"2007-08-09T08:45:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 8 Aug 2007, Junio C Hamano wrote:\n\n> This new world order is probably an improvement, and if the rules were \n> like this from the beginning, it would have been much nicer.  However, \n> this _is_ a change of semantics in the middle of the road, and probably \n> we will see many fallouts like this.  Unfortunate...  I am torn between \n> a cleaner semantics and the short-term pain...\n\nWith your warning at the beginning of the ReleaseNotes, I think it would \nbe the same amount of pain if we did it later.  It just would be...  \nlater.\n\nCiao,\nDscho\n"}]}