{"thread":{"id":"27246","subject":"[RFC] require-work-tree wants more than what its name says","startedAt":"2011-05-03T23:33:41Z","lastAt":"2011-05-05T17:31:08Z","messageCount":12,"participants":["Junio C Hamano","Jeff King","Michael J Gruber","Sverre Rabbelier"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166978","messageId":"7vhb9bgy0a.fsf@alter.siamese.dyndns.org","threadId":"27246","inReplyTo":null,"subject":"[RFC] require-work-tree wants more than what its name says","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-03T23:33:41Z","receivedAt":"2011-05-03T23:33:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Somebody tried \"git pull\" from a random place completely outside the work\ntree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct\nplaces, e.g.\n\n\tGIT_WORK_TREE=$HOME/git.git\n GIT_DIR=$GIT_WORK_TREE/.git\n export GIT_WORK_TREE GIT_DIR\n cd /tmp\n git pull\n\nAt the beginning of git-pull, we check \"require-work-tree\" and then\n\"cd-to-toplevel\". I _think_ the original intention when I wrote the\ncommand was \"we MUST have a work tree, our $(cwd) might not be at the\ntop-level directory of it\", and no stronger than that. That check is a\nvery sensible thing to do before doing cd-to-toplevel. We check that the\nplace we would want to go exists, and then go there.\n\nBut the implementation of require_work_tree we have today is quite\ndifferent. I don't have energy to dig the history, but currently it says:\n\n \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n \tdie \"fatal: $0 cannot be used without a working tree.\"\n\nWhich is completely bogus. Even though we may happen to be just outside\nof it right now, we may have a working tree that we can cd_to_toplevel\nback to.\n\nI recall there was a discussion sometime last year about this topic, and\nvaguely recall somebody proposed to swap the order of cd-to-toplevel and\nrequire-work-tree. While I agree that would sweep the issue under the rug,\nI think the right solution would be to apply the attached patch; and then\naudit all the callers that call \"require_work_tree\" to see if any of them\nmeant \"No, it is not Ok just to have working tree somewhere! I want you to\nbe IN that working tree when you call me\", and convert them to call the\nnew require_to_be_in_work_tree instead.\n\nThoughts?\n\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex aa16b83..0b25f12 100644\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -141,6 +141,13 @@ cd_to_toplevel () {\n }\n \n require_work_tree () {\n+\tif test \"z$(git rev-parse --is-bare-repository)\" != zfalse\n+\tthen\n+\t\tdie \"fatal: $0 cannot be used without a working tree.\"\n+\tfi\n+}\n+\n+require_to_be_in_work_tree () {\n \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n \tdie \"fatal: $0 cannot be used without a working tree.\"\n }\n"},{"id":"166998","messageId":"20110504073850.GA8512@sigill.intra.peff.net","threadId":"27246","inReplyTo":"7vhb9bgy0a.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-04T07:38:50Z","receivedAt":"2011-05-04T07:38:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 03, 2011 at 04:33:41PM -0700, Junio C Hamano wrote:\n\n> But the implementation of require_work_tree we have today is quite\n> different. I don't have energy to dig the history, but currently it says:\n> \n> \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n> \tdie \"fatal: $0 cannot be used without a working tree.\"\n> \n> Which is completely bogus. Even though we may happen to be just outside\n> of it right now, we may have a working tree that we can cd_to_toplevel\n> back to.\n\nYeah, I ran into this just recently when converting merge-one-file to\nuse git-sh-setup. I was surprised that require_work_tree also required\none to be inside it. My solution was to call cd_to_toplevel first, as\nyou noted.\n\n> I think the right solution would be to apply the attached patch; and then\n> audit all the callers that call \"require_work_tree\" to see if any of them\n> meant \"No, it is not Ok just to have working tree somewhere! I want you to\n> be IN that working tree when you call me\", and convert them to call the\n> new require_to_be_in_work_tree instead.\n\nYour proposed semantics for require_work_tree make much more sense to\nme, but I worry about compatibility. We can audit our in-tree scripts,\nbut git-sh-setup is part of the recommended API for external scripts,\nno? This change might break those scripts, so we would need to do the\nusual deprecation thing. I'm also concerned that the breakage might be\npretty severe. As in, not just \"script doesn't work\" but \"script\nsilently produces incorrect results\" or \"script deletes data\".\n\nFor example, the merge-one-file bug I fixed recently was silently\nproducing bogus merges because of a confusion over whether it was in the\nworkdir. Something like \"git clean\" would be even worse.\n\n-Peff\n"},{"id":"167002","messageId":"4DC112A1.5090805@drmicha.warpmail.net","threadId":"27246","inReplyTo":"7vhb9bgy0a.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-05-04T08:47:29Z","receivedAt":"2011-05-04T08:47:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 04.05.2011 01:33:\n> Somebody tried \"git pull\" from a random place completely outside the work\n> tree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct\n> places, e.g.\n> \n> \tGIT_WORK_TREE=$HOME/git.git\n> GIT_DIR=$GIT_WORK_TREE/.git\n> export GIT_WORK_TREE GIT_DIR\n> cd /tmp\n> git pull\n> \n> At the beginning of git-pull, we check \"require-work-tree\" and then\n> \"cd-to-toplevel\". I _think_ the original intention when I wrote the\n> command was \"we MUST have a work tree, our $(cwd) might not be at the\n> top-level directory of it\", and no stronger than that. That check is a\n> very sensible thing to do before doing cd-to-toplevel. We check that the\n> place we would want to go exists, and then go there.\n> \n> But the implementation of require_work_tree we have today is quite\n> different. I don't have energy to dig the history, but currently it says:\n> \n> \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n> \tdie \"fatal: $0 cannot be used without a working tree.\"\n> \n> Which is completely bogus. Even though we may happen to be just outside\n> of it right now, we may have a working tree that we can cd_to_toplevel\n> back to.\n> \n> I recall there was a discussion sometime last year about this topic, and\n> vaguely recall somebody proposed to swap the order of cd-to-toplevel and\n> require-work-tree. While I agree that would sweep the issue under the rug,\n\nI may have been that one that year or another...\n\n> I think the right solution would be to apply the attached patch; and then\n> audit all the callers that call \"require_work_tree\" to see if any of them\n> meant \"No, it is not Ok just to have working tree somewhere! I want you to\n> be IN that working tree when you call me\", and convert them to call the\n> new require_to_be_in_work_tree instead.\n> \n> Thoughts?\n\nSame thoughts as Jeff. git-sh-setup is explicitly meant to be used by\nscripters, and the users in git.git serve as an example how to use it.\nIf that usage changes it requires a long migration plan.\n\nThe only thing I can imagine doing right now is changing\nrequire_work_tree() to actually cd to toplevel when possible, so that\n(like before) on success we're really within. But that changes cwd, of\ncourse. In summary, a require_work_tree() now can have three assumptions\nwhen it returns with success:\n\n- we have a worktree\n- we are within worktree\n- cwd has not changed\n\nI'd rather break the last one than the second one, but breaking any may\nbe a problem, depending on the caller.\n\nMichael\n"},{"id":"167003","messageId":"20110504085014.GA9739@sigill.intra.peff.net","threadId":"27246","inReplyTo":"4DC112A1.5090805@drmicha.warpmail.net","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-04T08:50:14Z","receivedAt":"2011-05-04T08:50:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 04, 2011 at 10:47:29AM +0200, Michael J Gruber wrote:\n\n> The only thing I can imagine doing right now is changing\n> require_work_tree() to actually cd to toplevel when possible, so that\n> (like before) on success we're really within. But that changes cwd, of\n> course. In summary, a require_work_tree() now can have three assumptions\n> when it returns with success:\n> \n> - we have a worktree\n> - we are within worktree\n> - cwd has not changed\n> \n> I'd rather break the last one than the second one, but breaking any may\n> be a problem, depending on the caller.\n\nCheck out some of the older scripts in contrib/examples. Several of them\nrequire_work_tree, but do not cd_to_toplevel immediately; instead, they\ndo it much later for some specific bits.\n\nI didn't go through and analyze what would happen in each case if we did\nthe cd_to_toplevel first. I suspect some of it would be pretty mild\nbreakage (like \"git commit -F foo\" not finding \"foo\"). But it would be\nbreakage nonetheless.\n\n-Peff\n"},{"id":"167024","messageId":"7vliymfp4t.fsf@alter.siamese.dyndns.org","threadId":"27246","inReplyTo":"20110504073850.GA8512@sigill.intra.peff.net","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-04T15:42:58Z","receivedAt":"2011-05-04T15:42:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... but I worry about compatibility. We can audit our in-tree scripts,\n> but git-sh-setup is part of the recommended API for external scripts,\n> no?\n\nI am Ok with renaming the thing to \"require_work_tree_exists\", and all the\nworry will go away.\n"},{"id":"167025","messageId":"7vhb9afox9.fsf@alter.siamese.dyndns.org","threadId":"27246","inReplyTo":"20110504085014.GA9739@sigill.intra.peff.net","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-04T15:47:30Z","receivedAt":"2011-05-04T15:47:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Check out some of the older scripts in contrib/examples. Several of them\n> require_work_tree, but do not cd_to_toplevel immediately; instead, they\n> do it much later for some specific bits.\n\nAnother datapoint I found was \"clean\".\n\nIt used to say \"you have to be inside work tree\" in the scripted version.\nImagine what builtin/clean.c does today? It has NEED_WORK_TREE bit in the\ncommand table in git.c and that bit means \"We need to have a work tree\nthat we can later chdir to if we wanted to\".\n"},{"id":"167045","messageId":"20110504212848.GA27779@sigill.intra.peff.net","threadId":"27246","inReplyTo":"7vliymfp4t.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-04T21:28:48Z","receivedAt":"2011-05-04T21:28:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 04, 2011 at 08:42:58AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... but I worry about compatibility. We can audit our in-tree scripts,\n> > but git-sh-setup is part of the recommended API for external scripts,\n> > no?\n> \n> I am Ok with renaming the thing to \"require_work_tree_exists\", and all the\n> worry will go away.\n\nYeah, that seems like a fine solution to me.\n\n-Peff\n"},{"id":"167062","messageId":"7v62ppdhh5.fsf@alter.siamese.dyndns.org","threadId":"27246","inReplyTo":"20110504212848.GA27779@sigill.intra.peff.net","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-05T02:11:18Z","receivedAt":"2011-05-05T02:11:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, May 04, 2011 at 08:42:58AM -0700, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > ... but I worry about compatibility. We can audit our in-tree scripts,\n>> > but git-sh-setup is part of the recommended API for external scripts,\n>> > no?\n>> \n>> I am Ok with renaming the thing to \"require_work_tree_exists\", and all the\n>> worry will go away.\n>\n> Yeah, that seems like a fine solution to me.\n\nOk, then here is a reroll.\n\n-- >8 --\nSomebody tried \"git pull\" from a random place completely outside the work\ntree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct\nplaces, e.g.\n\n\tGIT_WORK_TREE=$HOME/git.git\n GIT_DIR=$GIT_WORK_TREE/.git\n export GIT_WORK_TREE GIT_DIR\n cd /tmp\n git pull\n\nAt the beginning of git-pull, we check \"require-work-tree\" and then\n\"cd-to-toplevel\". I _think_ the original intention when I wrote the\ncommand was \"we MUST have a work tree, our $(cwd) might not be at the\ntop-level directory of it\", and no stronger than that. That check is a\nvery sensible thing to do before doing cd-to-toplevel. We check that the\nplace we would want to go exists, and then go there.\n\nBut the implementation of require_work_tree we have today is quite\ndifferent. I don't have energy to dig the history, but currently it says:\n\n \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n \tdie \"fatal: $0 cannot be used without a working tree.\"\n\nWhich is completely bogus. Even though we may happen to be just outside\nof it right now, we may have a working tree that we can cd_to_toplevel\nback to.\n\nAdd a function \"require_work_tree_exists\" that implements the check\nthis function originally intended (this is so that third-party scripts\nthat rely on the current behaviour do not have to get broken), and\nupdate all the in-tree users to use it.\n\nSome comments:\n\n - The call in git-rebase--interactive.sh can actually be removed, I\n think, as it is always called from git-rebase.sh that has done\n cd_to_toplevel already.\n\n - I am not sure if git-submodule.sh correctly works with the \"as long as\n there is a working tree somewhere, it is OK\" semantics. It may have\n to stay \"require_work_tree\" to ensure that the $cwd is within the\n working tree.\n\nSigned-off-by: Junio C Hamano \n---\n\n Documentation/git-sh-setup.txt | 11 ++++++++---\n git-am.sh | 2 +-\n git-bisect.sh | 2 +-\n git-mergetool.sh | 2 +-\n git-pull.sh | 2 +-\n git-rebase--interactive.sh | 2 +-\n git-rebase.sh | 2 +-\n git-sh-setup.sh | 7 +++++++\n git-stash.sh | 2 +-\n git-submodule.sh | 2 +-\n 10 files changed, 23 insertions(+), 11 deletions(-)\n\ndiff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt\nindex 3da2413..1f02c4b 100644\n--- a/Documentation/git-sh-setup.txt\n+++ b/Documentation/git-sh-setup.txt\n@@ -58,9 +58,14 @@ cd_to_toplevel::\n \truns chdir to the toplevel of the working tree.\n \n require_work_tree::\n-\tchecks if the repository is a bare repository, and dies\n-\tif so. Used by scripts that require working tree\n-\t(e.g. `checkout`).\n+\tchecks if the current directory is within the working tree\n+\tof the repository, and otherwise dies.\n+\n+require_work_tree_exists::\n+\tchecks if the working tree associated with the repository\n+\texists, and otherwise dies. Often done before calling\n+\tcd_to_toplevel, which is impossible to do if there is no\n+\tworking tree.\n \n get_author_ident_from_commit::\n \toutputs code for use with eval to set the GIT_AUTHOR_NAME,\ndiff --git a/git-am.sh b/git-am.sh\nindex 6cdd591..430bbd5 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -39,7 +39,7 @@ rebasing* (internal use for git-rebase)\"\n . git-sh-setup\n prefix=$(git rev-parse --show-prefix)\n set_reflog_action am\n-require_work_tree\n+require_work_tree_exists\n cd_to_toplevel\n \n git var GIT_COMMITTER_IDENT >/dev/null ||\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex c21e33c..f46dda2 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -28,7 +28,7 @@ Please use \"git help bisect\" to get the full man page.'\n \n OPTIONS_SPEC=\n . git-sh-setup\n-require_work_tree\n+require_work_tree_exists\n \n _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n _x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\ndiff --git a/git-mergetool.sh b/git-mergetool.sh\nindex 2f8dc44..8a74d00 100755\n--- a/git-mergetool.sh\n+++ b/git-mergetool.sh\n@@ -14,7 +14,7 @@ OPTIONS_SPEC=\n TOOL_MODE=merge\n . git-sh-setup\n . git-mergetool--lib\n-require_work_tree\n+require_work_tree_exists\n \n # Returns true if the mode reflects a symlink\n is_symlink () {\ndiff --git a/git-pull.sh b/git-pull.sh\nindex eb87f49..7500b58 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -10,7 +10,7 @@ SUBDIRECTORY_OK=Yes\n OPTIONS_SPEC=\n . git-sh-setup\n set_reflog_action \"pull $*\"\n-require_work_tree\n+require_work_tree_exists\n cd_to_toplevel\n \n \ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 5873ba4..051a4ad 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -34,7 +34,7 @@ autosquash move commits that begin with squash!/fixup! under -i\n \"\n \n . git-sh-setup\n-require_work_tree\n+require_work_tree_exists\n \n DOTEST=\"$GIT_DIR/rebase-merge\"\n \ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex cbb0ea9..60a405d 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -31,7 +31,7 @@ SUBDIRECTORY_OK=Yes\n OPTIONS_SPEC=\n . git-sh-setup\n set_reflog_action rebase\n-require_work_tree\n+require_work_tree_exists\n cd_to_toplevel\n \n LF='\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex aa16b83..94e26ed 100644\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -140,6 +140,13 @@ cd_to_toplevel () {\n \t}\n }\n \n+require_work_tree_exists () {\n+\tif test \"z$(git rev-parse --is-bare-repository)\" != zfalse\n+\tthen\n+\t\tdie \"fatal: $0 cannot be used without a working tree.\"\n+\tfi\n+}\n+\n require_work_tree () {\n \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n \tdie \"fatal: $0 cannot be used without a working tree.\"\ndiff --git a/git-stash.sh b/git-stash.sh\nindex 7561b37..ce633f3 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -13,7 +13,7 @@ USAGE=\"list []\n SUBDIRECTORY_OK=Yes\n OPTIONS_SPEC=\n . git-sh-setup\n-require_work_tree\n+require_work_tree_exists\n cd_to_toplevel\n \n TMP=\"$GIT_DIR/.git-stash.$$\"\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 8b90589..f2a541e 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -15,7 +15,7 @@ USAGE=\"[--quiet] add [-b branch] [-f|--force] [--reference ] [--] >> I am Ok with renaming the thing to \"require_work_tree_exists\", and all the\n> >> worry will go away.\n> >\n> > Yeah, that seems like a fine solution to me.\n> \n> Ok, then here is a reroll.\n\nLooks sane. A few comments:\n\n> But the implementation of require_work_tree we have today is quite\n> different. I don't have energy to dig the history, but currently it says:\n> \n> \ttest \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" = true ||\n> \tdie \"fatal: $0 cannot be used without a working tree.\"\n> \n> Which is completely bogus. Even though we may happen to be just outside\n> of it right now, we may have a working tree that we can cd_to_toplevel\n> back to.\n\nAFAICT, it has been that way since 7ae3df8 (Use new semantics of\nis_bare/inside_git_dir/inside_work_tree, 2007-06-03), which is around\nthe time GIT_WORK_TREE came into existence.\n\nSo I think it was a matter of being overly strict then, either\naccidentally, or because it matched the prior semantics (which is that\nthere either was _no_ work tree, or you were in it).\n\n> Add a function \"require_work_tree_exists\" that implements the check\n> this function originally intended (this is so that third-party scripts\n> that rely on the current behaviour do not have to get broken), and\n> update all the in-tree users to use it.\n\nOverall, I think this is a good thing to do. And for the existing\nworking cases (i.e., when you are in the repo) it should be a no-op. It\nmay be worth doing some basic sanity tests to make sure that the scripts\nproperly work when GIT_DIR and GIT_WORK_TREE point elsewhere from the\ncurrent working directory. But I confess I am not excited about doing\nthe work to write those tests.\n\n-Peff\n"},{"id":"167069","messageId":"20110505042805.GA10547@sigill.intra.peff.net","threadId":"27246","inReplyTo":"20110505042319.GA10243@sigill.intra.peff.net","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-05T04:28:05Z","receivedAt":"2011-05-05T04:28:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 05, 2011 at 12:23:19AM -0400, Jeff King wrote:\n\n> > Add a function \"require_work_tree_exists\" that implements the check\n> > this function originally intended (this is so that third-party scripts\n> > that rely on the current behaviour do not have to get broken), and\n> > update all the in-tree users to use it.\n> \n> Overall, I think this is a good thing to do. And for the existing\n> working cases (i.e., when you are in the repo) it should be a no-op. It\n\nSorry, this should have been the more specific: \"i.e., when are you are\nin the _working tree_\".\n\n-Peff\n"},{"id":"167104","messageId":"BANLkTinaoopUxOHC0XaUxMLXj4pCXND+UA@mail.gmail.com","threadId":"27246","inReplyTo":"7v62ppdhh5.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-05-05T11:15:29Z","receivedAt":"2011-05-05T11:15:29Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, May 5, 2011 at 04:11, Junio C Hamano wrote:\n>  - I am not sure if git-submodule.sh correctly works with the \"as long as\n>   there is a working tree somewhere, it is OK\" semantics.  It may have\n>   to stay \"require_work_tree\" to ensure that the $cwd is within the\n>   working tree.\n\nSo do we need more tests for git-submodule to find out, or is this a\nhint to the submodule people to chime in? If so, should they be cc-ed?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"167131","messageId":"7v39kt9hr7.fsf@alter.siamese.dyndns.org","threadId":"27246","inReplyTo":"BANLkTinaoopUxOHC0XaUxMLXj4pCXND+UA@mail.gmail.com","subject":"Re: [RFC] require-work-tree wants more than what its name says","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-05T17:31:08Z","receivedAt":"2011-05-05T17:31:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> So do we need more tests for git-submodule to find out, or is this a\n> hint to the submodule people to chime in? If so, should they be cc-ed?\n\nI could queue a version without any conversion of in-tree users, so that\nstakeholders can verify and convert their use of require-work-tree to the\nnew saner alternative one by one. Actually I tend to like that better.\n\nI am not convinced myself if it is a sane use case to run \"git pull\" from\na totally random place and let fetch and merge magically happen somewhere\ncompletely unrelated to your current working directory only because you\nhave GIT_DIR and GIT_WORK_TREE set to begin with. After getting into a\nhabit of relying on these environment variables so much that you do not\neven think about their existence, you will reach a point where you have no\nidea where to go offhand when a merge conflict actually happens and you\nhave to go there to fix things up.\n"}]}