{"thread":{"id":"25486","subject":"[long] worktree setup cases","startedAt":"2010-10-20T08:59:00Z","lastAt":"2010-10-23T10:12:35Z","messageCount":17,"participants":["Nguyen Thai Ngoc Duy","Jonathan Nieder","Junio C Hamano","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"153860","messageId":"20101020085859.GA13135@do","threadId":"25486","inReplyTo":null,"subject":"[long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-20T08:59:00Z","receivedAt":"2010-10-20T08:59:00Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Hi,\n\nI want to know how I expect setup code to work and whether it matches\nmy expectation. So I list every possible cases and try to sum up what\ngit does and what I expect. Hopefully all corner cases are covered\n(and fixed later). It's not an easy read, but any comments are\nappreciated. If all go well, this document should be turned into test\ncases.\n\nAs a side note, Debian bug #575917 is case #17. I did not take into\naccount what setup_git_directory() does (which causes #575917)\nthough. Once the cleanup is done, setup_git_directory() should become\na one-liner around setup_git_directory_gently().\n\nAssumptions:\n\n1. When .git is a file and contains a relative path, I assume it is\n   relative to .git file's parent directory.  read_gitfile_gently()\n   function will make the path absolute, but it depends on (maybe\n   wrong) cwd.\n\n2. Relative path is preferred over absolute path.\n\n3. core.worktree is overidden by GIT_WORK_TREE\n\nThere are a few factors that affect gitdir/worktree/cwd/prefix setup.\nThose are:\n\n - GIT_DIR (or --git-dir)\n - GIT_WORK_TREE (or --work-tree)\n - core.worktree\n - .git is a file pointing to real .git directory\n - Bare repo\n\nSo there are 2^5 = 32 cases in total. Let's look at them one by\none. What describes here usually matches current code, except for\n\"should\" phrases/sentences. Note that I did not look at the code\ncarefully so I might misunderstand things.\n\nThe following questions must be answered for each case:\n\n0. What setup function handles that case?\n1. Is worktree available?\n2. Where is new cwd? Is it at worktree root?\n3. Prefix?\n4. Is (relative) $GIT_DIR accessible from current cwd?\n5. What if original cwd is outside worktree, or new cwd if it's not at\n   worktree root?\n\nTable of Contents\n=================\n1 Cases\n    1.1 Case 0, 8\n    1.2 Case 1, 4, 5, 9, 12, 13\n        1.2.1 cwd outside worktree\n    1.3 Case 2, 10\n    1.4 Case 3, 6, 7, 11, 14, 15\n        1.4.1 cwd outside worktree\n    1.5 Case 16, 24\n    1.6 Case 17, 20, 21, 25, 28, 29\n        1.6.1 cwd outside worktree\n    1.7 Case 18, 26\n    1.8 Case 19, 22, 23, 27, 30, 31\n\n\n1 Cases\n~~~~~~~~\n\nCase#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE\n0      0     0          0              0        0\n1      0     0          0              0        1\n2      0     0          0              1        0\n3      0     0          0              1        1\n4      0     0          1              0        0\n5      0     0          1              0        1\n6      0     0          1              1        0\n7      0     0          1              1        1\n8      0     1          0              0        0\n9      0     1          0              0        1\n10     0     1          0              1        0\n11     0     1          0              1        1\n12     0     1          1              0        0\n13     0     1          1              0        1\n14     0     1          1              1        0\n15     0     1          1              1        1\n16     1     0          0              0        0\n17     1     0          0              0        1\n18     1     0          0              1        0\n19     1     0          0              1        1\n20     1     0          1              0        0\n21     1     0          1              0        1\n22     1     0          1              1        0\n23     1     0          1              1        1\n24     1     1          0              0        0\n25     1     1          0              0        1\n26     1     1          0              1        0\n27     1     1          0              1        1\n28     1     1          1              0        0\n29     1     1          1              0        1\n30     1     1          1              1        0\n31     1     1          1              1        1\n\n1.1 Case 0, 8\n==============\n\nThe most used case, nothing special is set.\n\n0. setup_discovered_git_dir()\n1. work tree is .git dir's parent directory\n2. cwd is at worktree root, i.e. .git dir's parent dir\n3. prefix is calculated from original cwd\n4. git_dir is set to \".git\" (#0) or according to .git file, made\n   absolute (#8)\n5. N/A\n\nTODO: turn git_dir to relative in #8\n\n1.2 Case 1, 4, 5, 9, 12, 13\n============================\n\n0. setup_discovered_git_dir()\n1. work tree is set according to GIT_WORK_TREE (#1, #5, #9, #13) or\n   core.worktree (#4, #12)\n2. cwd is at worktree root, i.e. .git dir's parent dir\n3. prefix is calculated from original cwd\n4. git_dir is set to \".git\" (#1, #4, #5) or according to .git file,\n   made absolute (#9, #12, #13)\n\nTODO: turn git_dir to relative in #9, #12, #13\n\n1.2.1 cwd outside worktree\n---------------------------\n\nFIXME\n\n1.3 Case 2, 10\n===============\n\n0. setup_explicit_git_dir()\n1. worktree is set at cwd for legacy reason\n2. cwd is unchanged\n3. prefix is NULL\n4. git_dir is set according to GIT_DIR (#2) or according to .git file,\n   made absolute (#10)\n\nTODO: turn git_dir to relative path\n\nNote on #10: setup_git_env() is used to read .git file\n\n1.4 Case 3, 6, 7, 11, 14, 15\n=============================\n\nAnother normal case where worktree is at an unsual case.\n\n0. setup_explicit_git_dir()\n1. worktree is set according to GIT_WORK_TREE (#3, #7, #11, #15) or\n   core.worktree (#6, #14)\n2. cwd is moved to worktree root dir if original cwd is inside\n   worktree\n3. prefix is calculated if original cwd is inside worktree\n4. git_dir is set to GIT_DIR (#3, #6, #7) or according to .git file,\n   made absolute (#11, #14, #15)\n\nTODO: if GIT_DIR is relative, it is assumed relative to original cwd,\nso it breaks because cwd now is changed. Right now this does not\nhappen because git_dir is turned absolute. Although it's better to be\nrelative.\n\nTODO: turn git_dir to relative in #11, #14, #15\n\nFIXME on #11, #14, #15: setup_git_env() is used to read .git file. cwd\nby that time is worktree root, not .git's parent dir anymore.\n\n1.4.1 cwd outside worktree\n---------------------------\n\ncwd is left unchanged, prefix is NULL, which is sensible for full tree\noperations. is_inside_work_tree() returns 0, operations that require\nworktree should check and error out.\n\nTODO: File path output however may not be what user expected because\nit will be relative to worktree root, not original cwd.\n\n1.5 Case 16, 24\n================\n\nThe most used case, nothing special is set.\n\n0. setup_bare_git_dir()\n1. no worktree\n2. cwd is unchanged (actually it is moved back to original cwd)\n3. prefix is NULL\n4. git_dir is set in form \"../../../\" (or \".\") (#16) or according to\n   .git file, made absolute (#24)\n5. N/A\n\nTODO on #24: turn git_dir to relative\n\nFIXME on #24: cwd is not at .git's parent dir, so relative git_dir\nfails assumption #1.\n\n1.6 Case 17, 20, 21, 25, 28, 29\n================================\n\n0. setup_bare_git_dir()\n1. work tree is set according to GIT_WORK_TREE (#17, #21, #25, #29) or\n   core.worktree (#20, #28)\n2. cwd is unchanged (actually it is moved back to original\n   cwd).\n3. prefix is calculated from original cwd\n4. git_dir is set in form \"../../../\" (or \".\") (#17, #20, #21) or according to\n   .git file, made absolute (#25 , #28, #29).\n\nTODO: if core.bare = true, die()\n\nFIXME: cwd should be moved to worktree's root instead. Similarly,\ngit_dir should be recalculated relative to worktree's root\n\nTODO: turn git_dir to relative in #25, #28, #29 (or all if the above\nFIXME turns everything to absolute)\n\nNote on #25, #28, #9: pay attention to assumption #1 when the above\nFIXME is done.\n\n1.6.1 cwd outside worktree\n---------------------------\n\nFIXME\n\n1.7 Case 18, 26\n================\n\nThis is bare repo because of core.bare = true.\n\n0. setup_explicit_git_dir()\n1. no worktree\n2. cwd is unchanged\n3. prefix is NULL\n4. git_dir is set according to GIT_DIR (#18) or according to .git file,\n   made absolute (#126)\n\nFIXME: in current code, I believe this is actually #2/#10 (worktree is\nset). Should that be fixed??? \"Legacy reason\" hanging around so I'm\nnot sure.\n\nTODO: turn git_dir to relative path\n\nNote on #26: setup_git_env() is used to read .git file\n\n1.8 Case 19, 22, 23, 27, 30, 31\n================================\n\nThis is bare repo because of core.bare = true.\n\n0. setup_explicit_git_dir()\n1. worktree is set according to GIT_WORK_TREE (#19, #23, #27, #31) or\n   core.worktree (#22, #30)\n2. cwd is moved to worktree root dir if original cwd is inside\n   worktree\n3. prefix is calculated if original cwd is inside worktree\n4. git_dir is set to GIT_DIR (#19, #22, #23) or according to .git file,\n   made absolute (#27, #30, #31)\n5. N/A\n\nFIXME: just die() in check_repository_format_gently().\n-- \nDuy\n"},{"id":"153881","messageId":"20101020190709.GB10537@burratino","threadId":"25486","inReplyTo":"20101020085859.GA13135@do","subject":"Re: [long] worktree setup cases","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-20T19:07:09Z","receivedAt":"2010-10-20T19:07:09Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> 1. When .git is a file and contains a relative path, I assume it is\n>    relative to .git file's parent directory.  read_gitfile_gently()\n>    function will make the path absolute, but it depends on (maybe\n>    wrong) cwd.\n\nYep.\n\n> 2. Relative path is preferred over absolute path.\n\nI'm tempted to say: let's use absolute paths where it's more\nconvenient.  They can be changed to relative paths as an afterthought\nafter the bugs are gone.\n\nRelative paths have two big advantages over absolute paths,\nwhich are avoiding path traversal overhead and allowing paths\nlonger than PATH_MAX.  Supporting the latter consistently\nwould presumably require using openat() and co, though.\n\n> 3. core.worktree is overidden by GIT_WORK_TREE\n\nYeah.\n\n> So there are 2^5 = 32 cases in total. Let's look at them one by\n> one.\n\nThanks!  To summarize (and make sure I understand correctly):\nanything not following the below rules is a bug, yes?\n\nA. Weird cases.\n\n - using a .git file is just like setting GIT_DIR;\n - setting core.worktree is just like setting GIT_WORK_TREE.\n\nB. Repository search.\n\n - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to\n   \".\" (for legacy reasons).\n\n - otherwise, if original cwd was under repository, it will not\n   prompt a search for work tree, even if the repo happens\n   to be named \".git\" or core.bare is false.  That is, in\n   this case, GIT_WORK_TREE defaults to unset.\n\n - otherwise, if original cwd was under a directory containing\n   repository as \".git\", GIT_WORK_TREE defaults to that\n   directory (i.e., parent to .git dir).\n\n - otherwise, there is no repository.  GIT_DIR is unset,\n   GIT_WORK_TREE defaults to unset.\n\nC. Working directory and prefix\n\n - if GIT_WORK_TREE is still unset after repository search,\n   stay in the original cwd, prefix = NULL.\n\n - if original cwd is inside worktree, chdir to toplevel,\n   prefix = path to original cwd.\n\n - otherwise, stay in the original cwd, prefix = NULL.\n\nD. User-supplied relative paths.\n\n - path in .git file is relative to containing directory\n - path in GIT_DIR is relative to original cwd\n - paths in GIT_WORK_TREE and core.worktree are relative to\n   $GIT_DIR\n - paths passed to git commands are generally relative to\n   original cwd\n\nE. Internally used relative paths.\n\n - all paths are relative to current cwd.\n"},{"id":"153882","messageId":"20101020191849.GA17720@burratino","threadId":"25486","inReplyTo":"20101020190709.GB10537@burratino","subject":"Re: [long] worktree setup cases","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-20T19:18:49Z","receivedAt":"2010-10-20T19:18:49Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nOne correction.\n\nJonathan Nieder wrote:\n\n>  - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to\n>    \".\" (for legacy reasons).\n\nIn this case GIT_WORK_TREE defaults to the original cwd.\nGIT_WORK_TREE=. would have meant work tree == git dir, which\nis wrong.\n\nSorry for the noise.\n"},{"id":"153897","messageId":"7v8w1svate.fsf@alter.siamese.dyndns.org","threadId":"25486","inReplyTo":"20101020085859.GA13135@do","subject":"Re: [long] worktree setup cases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-20T21:00:45Z","receivedAt":"2010-10-20T21:00:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:\n\n> Assumptions:\n>\n> 1. When .git is a file and contains a relative path, I assume it is\n>    relative to .git file's parent directory.  read_gitfile_gently()\n>    function will make the path absolute, but it depends on (maybe\n>    wrong) cwd.\n\nOk.  I agree that a regular file .git that has \"gitdir: ../there\" in it\nshould be naming \"there\" directory next to the directory .git lives in.\nIt is insane for it to take $(cwd) into account.\n\n> There are a few factors that affect gitdir/worktree/cwd/prefix setup.\n> Those are:\n>\n>  - GIT_DIR (or --git-dir)\n>  - GIT_WORK_TREE (or --work-tree)\n>  - core.worktree\n>  - .git is a file pointing to real .git directory\n>  - Bare repo\n>\n> So there are 2^5 = 32 cases in total.\n\nHmm, why is core.worktree separate from the second item?  In any case, the\nthree mechanisms to specify the working tree should only be in effect when\nGIT_DIR/--git-dir is used, so the above are not orthogonal, and the total\ncount should be smaller than 32 cases.\n\n> The following questions must be answered for each case:\n>\n> 0. What setup function handles that case?\n> 1. Is worktree available?\n> 2. Where is new cwd? Is it at worktree root?\n> 3. Prefix?\n> 4. Is (relative) $GIT_DIR accessible from current cwd?\n> 5. What if original cwd is outside worktree, or new cwd if it's not at\n>    worktree root?\n\nAll good questions to ask, except for the last one which I cannot quite\nparse.\n\n> Table of Contents\n> =================\n> 1 Cases\n>     1.1 Case 0, 8\n>     1.2 Case 1, 4, 5, 9, 12, 13\n>         1.2.1 cwd outside worktree\n>     1.3 Case 2, 10\n>     1.4 Case 3, 6, 7, 11, 14, 15\n>         1.4.1 cwd outside worktree\n>     1.5 Case 16, 24\n>     1.6 Case 17, 20, 21, 25, 28, 29\n>         1.6.1 cwd outside worktree\n>     1.7 Case 18, 26\n>     1.8 Case 19, 22, 23, 27, 30, 31\n>\n>\n> 1 Cases\n> ~~~~~~~~\n>\n> Case#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE\n> 0      0     0          0              0        0\n> 8      0     1          0              0        0\n\nOk.\n\n> 1      0     0          0              0        1\n> 4      0     0          1              0        0\n> 5      0     0          1              0        1\n> 9      0     1          0              0        1\n> 12     0     1          1              0        0\n> 13     0     1          1              0        1\n\nHow does it make sense to have GIT_WORK_TREE without GIT_DIR?  Without\nGIT_DIR, we will run repository discovery, which means we will always go\nup to find a .git dir, and the reason for doing that is because we want to\nalso work in a subdirectory of a working tree (the very original git never\nworked from anywhere other than the root level of the working tree).  By\ndefinition, the root of the working tree is the same as in cases 0/8.\n\n> 2      0     0          0              1        0\n> 10     0     1          0              1        0\n\nIf you set GIT_DIR, we do no discovery, so git will work only from the\nroot level of the working tree (or bare repository operation) if you do\nnot tell us where the working tree is.\n\n> 3      0     0          0              1        1\n> 6      0     0          1              1        0\n> 7      0     0          1              1        1\n> 11     0     1          0              1        1\n> 14     0     1          1              1        0\n> 15     0     1          1              1        1\n\nWithout discovery, we know where the root level of the working tree is,\nand we know where the repository is, because you told us.  The answers to\nquestions 1-5, i.e. semantics observable by the end user, should be the\nsame as case 0/8 even though the internal codepath to achieve that,\ni.e. question 0, may be different.\n\n> 16     1     0          0              0        0\n> ...\n> 31     1     1          1              1        1\n\nShouldn't all of these 16 be the same, if the repository is bare?  What is\nyour definition of bareness?  core.bare?  In any case we should say \"you\nare using a bare repository, there is no working tree\" and cwd shouldn't\nchange in these cases.  They are all bare and there is no working tree.\n\nAlternatively, you could give precedence to core.worktree and friends, in\nwhich case these can go to the other categories in your description,\nignoring core.bare settings.  For example, 31 explicitly specifies where\nthe .git directory and the working tree are, which would fall into the\nsame category as 3,6,7,11,14,15.\n\nEither way is fine.\n\n> 1.1 Case 0, 8\n> ==============\n>\n> The most used case, nothing special is set.\n>\n> 0. setup_discovered_git_dir()\n> 1. work tree is .git dir's parent directory\n> 2. cwd is at worktree root, i.e. .git dir's parent dir\n> 3. prefix is calculated from original cwd\n> 4. git_dir is set to \".git\" (#0) or according to .git file, made\n>    absolute (#8)\n> 5. N/A\n>\n> TODO: turn git_dir to relative in #8\n\nOk.\n\n> 1.2 Case 1, 4, 5, 9, 12, 13\n\nAs I said already, isn't this a nonsense combination you should error out?\n\n> 1.3 Case 2, 10\n> ===============\n>\n> 0. setup_explicit_git_dir()\n> 1. worktree is set at cwd for legacy reason\n> 2. cwd is unchanged\n> 3. prefix is NULL\n> 4. git_dir is set according to GIT_DIR (#2) or according to .git file,\n>    made absolute (#10)\n>\n> TODO: turn git_dir to relative path\n>\n> Note on #10: setup_git_env() is used to read .git file\n\nOk.\n\n> 1.4 Case 3, 6, 7, 11, 14, 15\n> =============================\n>\n> Another normal case where worktree is at an unsual case.\n>\n> 0. setup_explicit_git_dir()\n> 1. worktree is set according to GIT_WORK_TREE (#3, #7, #11, #15) or\n>    core.worktree (#6, #14)\n> 2. cwd is moved to worktree root dir if original cwd is inside\n>    worktree\n> 3. prefix is calculated if original cwd is inside worktree\n> 4. git_dir is set to GIT_DIR (#3, #6, #7) or according to .git file,\n>    made absolute (#11, #14, #15)\n>\n> TODO: if GIT_DIR is relative, it is assumed relative to original cwd,\n> so it breaks because cwd now is changed. Right now this does not\n> happen because git_dir is turned absolute. Although it's better to be\n> relative.\n>\n> TODO: turn git_dir to relative in #11, #14, #15\n>\n> FIXME on #11, #14, #15: setup_git_env() is used to read .git file. cwd\n> by that time is worktree root, not .git's parent dir anymore.\n\nOk.\n\n> 1.4.1 cwd outside worktree\n> ---------------------------\n>\n> cwd is left unchanged, prefix is NULL, which is sensible for full tree\n> operations. is_inside_work_tree() returns 0, operations that require\n> worktree should check and error out.\n>\n> TODO: File path output however may not be what user expected because\n> it will be relative to worktree root, not original cwd.\n\nThis is operating out of bounds of the original design criteria; we\nprobably do not error out now, which is an original bug, but I understand\nthat you are trying to enhance this to reach into a submodule repository\nand its working tree from its superproject.  As long as we can make such\nan enhancement in a way that produces sensible and consistent output, that\nkind of change would be fine.\n\nI suspect that you would need to pass in \"make the path relative to this\"\nusing some means that do not exist in the current structure of the code.\n\nAlso I suspect that for the purpose of your enhancement, the first three\nlines of this paragraph would not be true.  Think of a case where you are\nat the superproject level and running a recursive grep into its submodule\nat \"nitfol\", that has contents recorded at the path \"xyzzy/frotz.txt\".\n\nIf you keep cwd unchanged, the path appears at nitfol/xyzzy/frotz.txt in\nthe working tree from the end user's point of view, so you need to pass\n\"nitfol/\" as a different kind of \"prefix\" that needs to be used to modify\nthe path recorded in the contents tracked by the submodule.  The grep\nrunning in the submodule will read xyzzy/frotz.txt from the index (which\nis how it notices which paths are of interest), use the \"nitfol/\" prefix\nto turn it into a path in the working tree, read from that file and report\nhits.  This is an example of an operation that clearly require a working\ntree, and does not have to error out.\n\nAlternatively, if you move cwd to the top of the working tree of the\nsubmodule, you would still need to pass \"nitfol/\" prefix, but it needs to\nbe used only in the output phase.  The grep running in the submodule will\nread xyzzy/frotz.txt from the index (which is how it notices which paths\nare of interest), read from the file in the working tree (relative to cwd\nwhich now is at the root level of the submodule), and use \"nitfol/\" as\noutput prefix when reporting.\n"},{"id":"153911","messageId":"AANLkTimzfxJFz2FRVCJ7b4+icXMxpQGNo0WGm_BXzXNy@mail.gmail.com","threadId":"25486","inReplyTo":"20101020190709.GB10537@burratino","subject":"Re: [long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-21T01:46:44Z","receivedAt":"2010-10-21T01:46:44Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>> So there are 2^5 = 32 cases in total. Let's look at them one by\n>> one.\n>\n> Thanks!  To summarize (and make sure I understand correctly):\n> anything not following the below rules is a bug, yes?\n\nLet's see.\n\n> A. Weird cases.\n>\n>  - using a .git file is just like setting GIT_DIR;\n\nYes, except that GIT_DIR can be detected early when cwd has not been\nmoved. When .git is found a file, cwd could have been changed.\n\n> B. Repository search.\n>\n>  - if GIT_DIR was set explicitly, GIT_WORK_TREE defaults to\n>   \".\" (for legacy reasons).\n\nCorrect.\n\n>  - otherwise, if original cwd was under repository, it will not\n>   prompt a search for work tree, even if the repo happens\n>   to be named \".git\" or core.bare is false.  That is, in\n>   this case, GIT_WORK_TREE defaults to unset.\n\nWhat do you mean by \"under repository\"? If the repo is /tmp/git/.git,\nthen cwd is at /tmp/git/.git?\n\n>  - otherwise, if original cwd was under a directory containing\n>   repository as \".git\", GIT_WORK_TREE defaults to that\n>   directory (i.e., parent to .git dir).\n\nYes.\n\n>  - otherwise, there is no repository.  GIT_DIR is unset,\n>   GIT_WORK_TREE defaults to unset.\n\n- Otherwise, move up one dir and repeat?\n\n> C. Working directory and prefix\n>\n>  - if GIT_WORK_TREE is still unset after repository search,\n>   stay in the original cwd, prefix = NULL.\n\nif GIT_WORK_TREE and core.worktree are still unset, we get a bare repo\nhere (or force it to be a bare repo), so yes, cwd should stay in\noriginal cwd and prefix = NULL.\n\n>  - if original cwd is inside worktree, chdir to toplevel,\n>   prefix = path to original cwd.\n\nYes.\n\n>  - otherwise, stay in the original cwd, prefix = NULL.\n\nI'm not really happy with this, which is why I wrote the\n--cwd-to-worktree and --worktree-to-cwd patch. But this should be\nenough for full-tree operations to work, so yes.\n\n> D. User-supplied relative paths.\n>\n>  - path in .git file is relative to containing directory\n>  - path in GIT_DIR is relative to original cwd\n>  - paths in GIT_WORK_TREE and core.worktree are relative to\n>   $GIT_DIR\n\nI think $GIT_WORK_TREE is relative to original cwd. Yes, core.worktree\nshould be relative to $GIT_DIR.\n\n>  - paths passed to git commands are generally relative to\n>   original cwd\n\nAnd filename output should also be relative to original cwd (except a\nfew special, like diff output).\n\n> E. Internally used relative paths.\n>\n>  - all paths are relative to current cwd.\n\nYes.\n-- \nDuy\n"},{"id":"153937","messageId":"AANLkTi=dUtRrOwksXWrJ3v-TGAQPBRAduLgjS9CE8hJd@mail.gmail.com","threadId":"25486","inReplyTo":"7v8w1svate.fsf@alter.siamese.dyndns.org","subject":"Re: [long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-21T02:23:28Z","receivedAt":"2010-10-21T02:23:28Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 21, 2010 at 4:00 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> There are a few factors that affect gitdir/worktree/cwd/prefix setup.\n>> Those are:\n>>\n>>  - GIT_DIR (or --git-dir)\n>>  - GIT_WORK_TREE (or --work-tree)\n>>  - core.worktree\n>>  - .git is a file pointing to real .git directory\n>>  - Bare repo\n>>\n>> So there are 2^5 = 32 cases in total.\n> Hmm, why is core.worktree separate from the second item?\n\nIt's how the code does it. GIT_WORK_TREE can be detected early, when\ncwd has not been moved. When core.worktree is found, cwd could be\nsomewhere. I need to separate those cases to make sure cwd is not\nmisused after it's been moved.\n\n> In any case, the\n> three mechanisms to specify the working tree should only be in effect when\n> GIT_DIR/--git-dir is used, so the above are not orthogonal, and the total\n> count should be smaller than 32 cases.\n\nGood to hear. I forgot that GIT_DIR must be set for the three\nmechanisms in effect.\n\n>> The following questions must be answered for each case:\n>>\n>> 0. What setup function handles that case?\n>> 1. Is worktree available?\n>> 2. Where is new cwd? Is it at worktree root?\n>> 3. Prefix?\n>> 4. Is (relative) $GIT_DIR accessible from current cwd?\n>> 5. What if original cwd is outside worktree, or new cwd if it's not at\n>>    worktree root?\n>\n> All good questions to ask, except for the last one which I cannot quite\n> parse.\n\nSkip \"or new cwd... worktree root\" part.\n\n>> 1 Cases\n>> ~~~~~~~~\n>>\n>> Case#  Bare  .git-file  core.worktree  GIT_DIR  GIT_WORK_TREE\n>> 0      0     0          0              0        0\n>> 8      0     1          0              0        0\n>\n> Ok.\n>\n>> 1      0     0          0              0        1\n>> 4      0     0          1              0        0\n>> 5      0     0          1              0        1\n>> 9      0     1          0              0        1\n>> 12     0     1          1              0        0\n>> 13     0     1          1              0        1\n>\n> How does it make sense to have GIT_WORK_TREE without GIT_DIR?  Without\n> GIT_DIR, we will run repository discovery, which means we will always go\n> up to find a .git dir, and the reason for doing that is because we want to\n> also work in a subdirectory of a working tree (the very original git never\n> worked from anywhere other than the root level of the working tree).  By\n> definition, the root of the working tree is the same as in cases 0/8.\n\nOK.\n\n>> 2      0     0          0              1        0\n>> 10     0     1          0              1        0\n>\n> If you set GIT_DIR, we do no discovery, so git will work only from the\n> root level of the working tree (or bare repository operation) if you do\n> not tell us where the working tree is.\n\nOK\n\n>> 3      0     0          0              1        1\n>> 6      0     0          1              1        0\n>> 7      0     0          1              1        1\n>> 11     0     1          0              1        1\n>> 14     0     1          1              1        0\n>> 15     0     1          1              1        1\n>\n> Without discovery, we know where the root level of the working tree is,\n> and we know where the repository is, because you told us.  The answers to\n> questions 1-5, i.e. semantics observable by the end user, should be the\n> same as case 0/8 even though the internal codepath to achieve that,\n> i.e. question 0, may be different.\n\nOK too.\n\n>> 16     1     0          0              0        0\n>> ...\n>> 31     1     1          1              1        1\n>\n> Shouldn't all of these 16 be the same, if the repository is bare?  What is\n> your definition of bareness?  core.bare?  In any case we should say \"you\n> are using a bare repository, there is no working tree\" and cwd shouldn't\n> change in these cases.  They are all bare and there is no working tree.\n\nBetter this way. Although some sanity checks can be used. Like setting\ncore.bare and explicitly requesting worktree is insane.\n\n> Alternatively, you could give precedence to core.worktree and friends, in\n> which case these can go to the other categories in your description,\n> ignoring core.bare settings.  For example, 31 explicitly specifies where\n> the .git directory and the working tree are, which would fall into the\n> same category as 3,6,7,11,14,15.\n\nI don't want to ignore core.bare. If there are bare/worktree\nconflicts, notify users. There are cases that a normal repo tends to\nbecome a bare repo for just one operation. It's when \".\" is found a\nrepo, handled by setup_bare_git_dir(). In these cases, we might want\nto consider core.worktree and friends again.\n\n> Either way is fine.\n-- \nDuy\n"},{"id":"153939","messageId":"20101021033042.GA1891@burratino","threadId":"25486","inReplyTo":"AANLkTimzfxJFz2FRVCJ7b4+icXMxpQGNo0WGm_BXzXNy@mail.gmail.com","subject":"Re: [long] worktree setup cases","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-21T03:30:42Z","receivedAt":"2010-10-21T03:30:42Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>>  - otherwise, if original cwd was under repository,\n[...]\n>>              GIT_WORK_TREE defaults to unset.\n>\n> What do you mean by \"under repository\"? If the repo is /tmp/git/.git,\n> then cwd is at /tmp/git/.git?\n\nI meant if the original cwd lies within the repository.\n\nExample:\n\n repo\t\t/tmp/git/.git\n starting cwd\t/tmp/git/.git/objects/pack\n\n>> D. User-supplied relative paths.\n>>\n>>  - path in .git file is relative to containing directory\n>>  - path in GIT_DIR is relative to original cwd\n>>  - paths in GIT_WORK_TREE and core.worktree are relative to\n>>   $GIT_DIR\n>\n> I think $GIT_WORK_TREE is relative to original cwd.\n\ngit.txt is confusing, then.  Actually it has some other insights:\n\n --work-tree=<path>\n\tSet the path to the working tree. The value\n\twill not be used in combination with\n\trepositories found automatically in a .git\n\tdirectory (i.e. $GIT_DIR is not set).\n\nSo GIT_WORK_TREE should be discarded or warned about when GIT_DIR is\nnot set. (?)\n\n\tThis can also be controlled by setting the\n\tGIT_WORK_TREE environment variable and the\n\tcore.worktree configuration variable. It can be\n\tan absolute path or relative path to the\n\tdirectory specified by --git-dir or GIT_DIR.\n\nThis is where I got the impression about relative paths.\n\n\tNote: If --git-dir or GIT_DIR are specified but\n\tnone of --work-tree, GIT_WORK_TREE and\n\tcore.worktree is specified, the current working\n\tdirectory is regarded as the top directory of\n\tyour working tree.\n\nNice to see this case is documented.\n\n> Yes, core.worktree\n> should be relative to $GIT_DIR.\n\nSpeaking of which, it is not clear to me that core.worktree should\nfall under the forbidden case discussed above.  If it does, what is\nthe point of making it configurable?\n\n> Yes.\n\nThanks for checking.\n\nJonathan\n"},{"id":"153955","messageId":"AANLkTikwApJ2EtJNiOZPHVrz6seJNP-zEqzH_b62ksLf@mail.gmail.com","threadId":"25486","inReplyTo":"20101021033042.GA1891@burratino","subject":"Re: [long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-21T12:50:30Z","receivedAt":"2010-10-21T12:50:30Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 21, 2010 at 10:30 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Nguyen Thai Ngoc Duy wrote:\n>> On Thu, Oct 21, 2010 at 2:07 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>\n>>>  - otherwise, if original cwd was under repository,\n> [...]\n>>>              GIT_WORK_TREE defaults to unset.\n>>\n>> What do you mean by \"under repository\"? If the repo is /tmp/git/.git,\n>> then cwd is at /tmp/git/.git?\n>\n> I meant if the original cwd lies within the repository.\n>\n> Example:\n>\n>  repo           /tmp/git/.git\n>  starting cwd   /tmp/git/.git/objects/pack\n\nOK it's considered a bare repo, so no worktree.\n\n>>> D. User-supplied relative paths.\n>>>\n>>>  - path in .git file is relative to containing directory\n>>>  - path in GIT_DIR is relative to original cwd\n>>>  - paths in GIT_WORK_TREE and core.worktree are relative to\n>>>   $GIT_DIR\n>>\n>> I think $GIT_WORK_TREE is relative to original cwd.\n>\n> git.txt is confusing, then.  Actually it has some other insights:\n>\n>  --work-tree=<path>\n>        Set the path to the working tree. The value\n>        will not be used in combination with\n>        repositories found automatically in a .git\n>        directory (i.e. $GIT_DIR is not set).\n>\n> So GIT_WORK_TREE should be discarded or warned about when GIT_DIR is\n> not set. (?)\n\nYeah. Junio reminded me in another mail. It should warn (at least, me).\n\n>        This can also be controlled by setting the\n>        GIT_WORK_TREE environment variable and the\n>        core.worktree configuration variable. It can be\n>        an absolute path or relative path to the\n>        directory specified by --git-dir or GIT_DIR.\n>\n> This is where I got the impression about relative paths.\n\nHmm.. OK then. So worktree can be relative to gitdir, which in turn\ncan be relative to original cwd. Fun.\n\n>        Note: If --git-dir or GIT_DIR are specified but\n>        none of --work-tree, GIT_WORK_TREE and\n>        core.worktree is specified, the current working\n>        directory is regarded as the top directory of\n>        your working tree.\n>\n> Nice to see this case is documented.\n>\n>> Yes, core.worktree\n>> should be relative to $GIT_DIR.\n>\n> Speaking of which, it is not clear to me that core.worktree should\n> fall under the forbidden case discussed above.  If it does, what is\n> the point of making it configurable?\n\nI was not the one who introduced core.worktree, so I can't really\ntell. Maybe less keystrokes? You know, \"GIT_DIR=foo.git git foo\" is\nshorter than \"GIT_DIR=foo.git GIT_WORK_TREE=/path/to/somewhere git\nfoo\". I tend to think that core.worktree is always effective\nregardless $GIT_DIR env setting. But I was wrong.\n\nAlso the \"relative to $GIT_DIR\" may be confusing. If $GIT_DIR points\nto a file that points to a true repo, then to which one it is\nrelative?\n-- \nDuy\n"},{"id":"153976","messageId":"20101021160134.GA3732@burratino","threadId":"25486","inReplyTo":"AANLkTikwApJ2EtJNiOZPHVrz6seJNP-zEqzH_b62ksLf@mail.gmail.com","subject":"Re: [long] worktree setup cases","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-21T16:01:34Z","receivedAt":"2010-10-21T16:01:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> On Thu, Oct 21, 2010 at 10:30 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>> Speaking of which, it is not clear to me that core.worktree should\n>> fall under the forbidden case discussed above.  If it does, what is\n>> the point of making it configurable?\n>\n> I was not the one who introduced core.worktree, so I can't really\n> tell. Maybe less keystrokes?\n\nYeah, it seems you're totally right. :(\n\nSo in clarifying the semantics, core.worktree without GIT_DIR should\nbe forbidden.  But consider this a feature request.  By the time\ncore.worktree has been read, it is obvious what the GIT_DIR was\nsupposed to be:\n\nReferences:\n\n - v0 (GIT_TOP_DIR):\n   http://thread.gmane.org/gmane.comp.version-control.git/38382\n - v1 (GIT_WORK_DIR):\n   http://thread.gmane.org/gmane.comp.version-control.git/41902\n - v2 (GIT_WORK_TREE):\n   http://thread.gmane.org/gmane.comp.version-control.git/42416\n"},{"id":"153997","messageId":"20101021185132.GB28700@nibiru.local","threadId":"25486","inReplyTo":"AANLkTikwApJ2EtJNiOZPHVrz6seJNP-zEqzH_b62ksLf@mail.gmail.com","subject":"Re: [long] worktree setup cases","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-10-21T18:51:32Z","receivedAt":"2010-10-21T18:51:32Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n\n> > Example:\n> >\n> >  repo           /tmp/git/.git\n> >  starting cwd   /tmp/git/.git/objects/pack\n> \n> OK it's considered a bare repo, so no worktree.\n\nNot necessarily: if config tells it's a non-bare repo, we could\nassume, the worktree is where core.worktree tells (which per\ndefault is \"../\" - relative to gitdir).\n\nBut currently it seems to be implemented as you said: running\ngit-status from within gitdir tells:\n\n    \"fatal: This operation must be run in a work tree\"\n\nThat's not really bad, but sometimes a bit inconvenient.\n\n> Also the \"relative to $GIT_DIR\" may be confusing. If $GIT_DIR points\n> to a file that points to a true repo, then to which one it is\n> relative?\n\nDespite the fact that I doubt the usefulness of an .git file at\nall, it IMHO should be interpreted as an kind of userland symlink.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone:  +49 36207 519931  email: weigelt@metux.de\n mobile: +49 151 27565287  icq:   210169427         skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"154000","messageId":"20101021190146.GC28700@nibiru.local","threadId":"25486","inReplyTo":"7v8w1svate.fsf@alter.siamese.dyndns.org","subject":"Re: [long] worktree setup cases","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-10-21T19:01:47Z","receivedAt":"2010-10-21T19:01:47Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Junio C Hamano <gitster@pobox.com> wrote:\n\n> If you set GIT_DIR, we do no discovery, so git will work only from the\n> root level of the working tree (or bare repository operation) if you do\n> not tell us where the working tree is.\n\nWell, we could look at config whether it's an non-bare repo and then\nlookup worktree via core.worktree (which would default to \"../\").\n\n\nBTW: the whole discovery process IMHO should start w/ looking for \nthe gitdir. Could be done this way:\n\na) explicitly given (via GIT_DIR or --git-dir), take this one.\nb) else: recursively scan for a valid .git dir from cwd upstairs to /\n\nOnce we've found gitdir, we can look for the worktree. Again:\n\na) explicitly given, then take it\nb) bare repo: dont have any, bail out\nc) non-bare repo: look up via core.worktree (w/ default to $GIT_DIR/../)\n \n> Shouldn't all of these 16 be the same, if the repository is bare?  What is\n> your definition of bareness?  core.bare?  In any case we should say \"you\n> are using a bare repository, there is no working tree\" and cwd shouldn't\n> change in these cases.  They are all bare and there is no working tree.\n\nACK. In a bare repo, the worktree lookup will fail per definition, so\nworktree operations can only run with having it explicitly given.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone:  +49 36207 519931  email: weigelt@metux.de\n mobile: +49 151 27565287  icq:   210169427         skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"154043","messageId":"7vlj5rrvrd.fsf@alter.siamese.dyndns.org","threadId":"25486","inReplyTo":"20101021190146.GC28700@nibiru.local","subject":"Re: [long] worktree setup cases","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-21T23:06:30Z","receivedAt":"2010-10-21T23:06:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Enrico Weigelt <weigelt@metux.de> writes:\n\n> * Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> If you set GIT_DIR, we do no discovery, so git will work only from the\n>> root level of the working tree (or bare repository operation) if you do\n>> not tell us where the working tree is.\n>\n> Well, we could look at config whether it's an non-bare repo and then\n> lookup worktree via core.worktree (which would default to \"../\").\n\ncore.worktree is \"you tell us where the working tree is\" in the above.\n\n> BTW: the whole discovery process IMHO should start w/ looking for \n> the gitdir. Could be done this way:\n\nThat should be more or less what we have been doing since the first day we\nstarted supporting git operations from subdirectories around d288a70\n([PATCH] Make \"git diff\" work inside relative subdirectories, 2005-08-16).\n\nIt is possible that we might have broken some over the course while adding\ncore.worktree and GIT_WORK_TREE support, but I doubt it.\n"},{"id":"154067","messageId":"AANLkTinS0co8TMmyRCQ4Xe9+pDR-uUn20WNQwYJEAQea@mail.gmail.com","threadId":"25486","inReplyTo":"20101021185132.GB28700@nibiru.local","subject":"Re: [long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-22T00:34:36Z","receivedAt":"2010-10-22T00:34:36Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Oct 22, 2010 at 1:51 AM, Enrico Weigelt <weigelt@metux.de> wrote:\n>> Also the \"relative to $GIT_DIR\" may be confusing. If $GIT_DIR points\n>> to a file that points to a true repo, then to which one it is\n>> relative?\n>\n> Despite the fact that I doubt the usefulness of an .git file at\n> all, it IMHO should be interpreted as an kind of userland symlink.\n\nI do find .git file useful. I put my worktree in a server where it can\nbe wiped out completely. So I don't want to put my .git there. .git\nfile can be used this case so I don't have to set\nGIT_DIR/GIT_WORK_TREE every time and my .git is safe elsewhere.\n-- \nDuy\n"},{"id":"154100","messageId":"20101022050011.GA27179@nibiru.local","threadId":"25486","inReplyTo":"AANLkTinS0co8TMmyRCQ4Xe9+pDR-uUn20WNQwYJEAQea@mail.gmail.com","subject":"Re: [long] worktree setup cases","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-10-22T05:00:12Z","receivedAt":"2010-10-22T05:00:12Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Fri, Oct 22, 2010 at 1:51 AM, Enrico Weigelt <weigelt@metux.de> wrote:\n> >> Also the \"relative to $GIT_DIR\" may be confusing. If $GIT_DIR points\n> >> to a file that points to a true repo, then to which one it is\n> >> relative?\n> >\n> > Despite the fact that I doubt the usefulness of an .git file at\n> > all, it IMHO should be interpreted as an kind of userland symlink.\n> \n> I do find .git file useful. I put my worktree in a server where it can\n> be wiped out completely. So I don't want to put my .git there. .git\n> file can be used this case so I don't have to set\n> GIT_DIR/GIT_WORK_TREE every time and my .git is safe elsewhere.\n\nWhy not using a symlink here ?\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone:  +49 36207 519931  email: weigelt@metux.de\n mobile: +49 151 27565287  icq:   210169427         skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"154102","messageId":"20101022052855.GA786@burratino","threadId":"25486","inReplyTo":"20101022050011.GA27179@nibiru.local","subject":".git file (Re: [long] worktree setup cases)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-22T05:28:55Z","receivedAt":"2010-10-22T05:28:55Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Enrico Weigelt wrote:\n\n> Why not using a symlink here ?\n\nSuppose I wonder just that.  grepping through setup.c for \".git file\",\nI find the function read_gitfile_gently() --- why was that added?\n\n$ git log -Sread_gitfile_gently setup.c\ncommit b44ebb19e3234c5dffe9869ceac5408bb44c2e20\nAuthor: Lars Hjemli <hjemli@gmail.com>\nDate:   Wed Feb 20 23:13:13 2008 +0100\n\n    Add platform-independent .git \"symlink\"\n    \n    This patch allows .git to be a regular textfile containing the path of\n    the real git directory (prefixed with \"gitdir: \"), which can be useful on\n    platforms lacking support for real symlinks.\n    \n    Signed-off-by: Lars Hjemli <hjemli@gmail.com>\n    Signed-off-by: Junio C Hamano <gitster@pobox.com>\n\nHope that helps.\n"},{"id":"154104","messageId":"AANLkTi=7R6nfdXQ10hme87xPPVnomZu+m9A_SZ8j8dpk@mail.gmail.com","threadId":"25486","inReplyTo":"20101022050011.GA27179@nibiru.local","subject":"Re: [long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-22T05:36:17Z","receivedAt":"2010-10-22T05:36:17Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Oct 22, 2010 at 12:00 PM, Enrico Weigelt <weigelt@metux.de> wrote:\n> * Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n>> On Fri, Oct 22, 2010 at 1:51 AM, Enrico Weigelt <weigelt@metux.de> wrote:\n>> >> Also the \"relative to $GIT_DIR\" may be confusing. If $GIT_DIR points\n>> >> to a file that points to a true repo, then to which one it is\n>> >> relative?\n>> >\n>> > Despite the fact that I doubt the usefulness of an .git file at\n>> > all, it IMHO should be interpreted as an kind of userland symlink.\n>>\n>> I do find .git file useful. I put my worktree in a server where it can\n>> be wiped out completely. So I don't want to put my .git there. .git\n>> file can be used this case so I don't have to set\n>> GIT_DIR/GIT_WORK_TREE every time and my .git is safe elsewhere.\n>\n> Why not using a symlink here ?\n\nParanoia. A fault in Makefile's clean rule may make deletion follow\nsymlinks. Also symlinks are not available everywhere.\n-- \nDuy\n"},{"id":"154232","messageId":"AANLkTin-W_GF97APs8fHJim0pFbNDGKv6KAnWPDVbiKP@mail.gmail.com","threadId":"25486","inReplyTo":"20101021160134.GA3732@burratino","subject":"Re: [long] worktree setup cases","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-10-23T10:12:35Z","receivedAt":"2010-10-23T10:12:35Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Oct 21, 2010 at 11:01 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Nguyen Thai Ngoc Duy wrote:\n>> On Thu, Oct 21, 2010 at 10:30 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>\n>>> Speaking of which, it is not clear to me that core.worktree should\n>>> fall under the forbidden case discussed above.  If it does, what is\n>>> the point of making it configurable?\n>>\n>> I was not the one who introduced core.worktree, so I can't really\n>> tell. Maybe less keystrokes?\n>\n> Yeah, it seems you're totally right. :(\n\nActually I have my part in this mess too: f5e025a (Documentation:\nalways respect core.worktree if set - 2009-12-29). I probably just\nupdated the document according to the code. It matches what Enrico\nexpects (i.e after .git discovery, worktree defaults is \"../\", if\ncore.worktree exists, follow it instead). Going back to the first\ncommit that introduced separate worktree, 892c41b (introduce\nGIT_WORK_TREE to specify the work tree - 2007-06-06), core.worktree is\nno different than --work-tree.\n\nSo what should it behave? Either revert f5e025a and update the code to\ndisregard/warn core.worktree if GIT_DIR/--work-tree is unset, or keep\nthe current behavior, i.e. core.worktree is different from\n--work-tree/GIT_WORK_TREE.\n\nThe cleanup commit, e90fdc3 (Clean up work-tree handling -\n2007-08-01), also gives something interesting regarding bare repo:\n\"--work-tree=bla overrides GIT_WORK_TREE, _which overrides core.bare =\ntrue_, which overrides core.worktree, which overrides GIT_DIR/.. when\nGIT_DIR ends in /.git, which overrides the directory in which .git/\nwas found.\". I don't like this overriding chain, which is why I\nproposed to die() if core.bare is set and worktree is explicitly\nspecified.\n-- \nDuy\n"}]}