{"thread":{"id":"15956","subject":"[PATCH] -C/--chdir command line option","startedAt":"2008-10-19T00:02:27Z","lastAt":"2008-10-20T13:59:46Z","messageCount":10,"participants":["Maciej Pasternacki","Jeff King","Junio C Hamano","Alex Riesen","Nguyen Thai Ngoc Duy","Michael J Gruber"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"93402","messageId":"20081019000227.GA9423@charybdis.dreamhost.com","threadId":"15956","inReplyTo":null,"subject":"[PATCH] -C/--chdir command line option","fromName":"Maciej Pasternacki","fromEmail":"maciej@pasternacki.net","sentAt":"2008-10-19T00:02:27Z","receivedAt":"2008-10-19T00:02:27Z","isPatch":true,"sender":{"key":"maciej@pasternacki.net","avatar":"https://gravatar.com/avatar/6485c5851d08fb9492fd6b9528e10b730c82320a0665560401c417a5f9209773?d=mp&s=160"},"body":"In my project cl-librarian, which is a layer built upon different\nversion control systems, I need to run git pull, but start it from\noutside of work tree; however, pull needs to be in work tree (as in\ngetcwd()) in order to update said work tree. --git-dir and\n--work-tree options don't work; I discussed it on #git yesterday,\nand it turned out that this issue is nontrivial:\n\n231701 hm, require_work_tree checks if you are _in_ the work tree,\n and pull only switches to the work tree after the require_work_tree\n call...\n231710 looks like a chicken-egg-problem\n231715 japhy`: spawning commands requires forking anyway, so do chdir in\n forked process\n231739 if you move the \"cd_to_toplevel\" call up in git-push, so that\n it happens before require_work_tree, then it works\n231747 shd: yup, that would be a workaround, but I tried to avoid\n shell-quoting ;)\n231749 doener: push?\n231756 ehrm, pull\n channel #git\n231820 but I guess doing the cd_to_toplevel first might break somehow\n if there is no working tree...\n231843 Oh.\n231922 I'd just ask on the list about that.\n\nI don't like the idea of doing chdir() myself -- this would expose me to a\nwhole world of portability issues, and I don't feel like spending time to\nfigure out how to do a fork on windows ;) the best workaround that occured to\nme was adding -C/--chdir option to main git binary, like one that Make accepts.\nThis fixed my problem, I paste the resulting patch below:\n\n>From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001\nFrom: Maciej Pasternacki \nDate: Sun, 19 Oct 2008 01:33:49 +0200\nSubject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.\n\nSigned-off-by: Maciej Pasternacki \n---\n Documentation/git.txt | 6 +++++-\n git.c | 9 ++++++++-\n 2 files changed, 13 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex df420ae..6676d68 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -12,7 +12,7 @@ SYNOPSIS\n 'git' [--version] [--exec-path[=GIT_EXEC_PATH]]\n [-p|--paginate|--no-pager]\n [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n- [--help] COMMAND [ARGS]\n+ [-C DIRECTORY|--chdir=DIRECTORY] [--help] COMMAND [ARGS]\n \n DESCRIPTION\n -----------\n@@ -185,6 +185,10 @@ help ...`.\n \tenvironment is not set, it is set to the current working\n \tdirectory.\n \n+-C ::\n+--chdir=::\n+\tChange working directory before doing anything.\n+\n \n FURTHER DOCUMENTATION\n ---------------------\ndiff --git a/git.c b/git.c\nindex 89feb0b..8c97671 100644\n--- a/git.c\n+++ b/git.c\n@@ -115,7 +115,14 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)\n \t\t\tsetenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);\n \t\t\tif (envchanged)\n \t\t\t\t*envchanged = 1;\n-\t\t} else {\n+\t\t} else if (!strcmp(cmd, \"-C\") || !strcmp(cmd, \"--chdir\")) {\n+ chdir((*argv)[1]);\n+ (*argv)++;\n+ (*argc)--;\n+ handled++;\n+ } else if (!prefixcmp(cmd,\"--chdir=\")) {\n+ chdir(cmd+8);\n+ } else {\n \t\t\tfprintf(stderr, \"Unknown option: %s\\n\", cmd);\n \t\t\tusage(git_usage_string);\n \t\t}\n-- \n1.6.0.1\n"},{"id":"93430","messageId":"20081019131745.GA8643@coredump.intra.peff.net","threadId":"15956","inReplyTo":"20081019000227.GA9423@charybdis.dreamhost.com","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-19T13:17:45Z","receivedAt":"2008-10-19T13:17:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 18, 2008 at 05:02:27PM -0700, Maciej Pasternacki wrote:\n\n> In my project cl-librarian, which is a layer built upon different\n> version control systems, I need to run git pull, but start it from\n> outside of work tree; however, pull needs to be in work tree (as in\n> getcwd()) in order to update said work tree. --git-dir and\n> --work-tree options don't work; I discussed it on #git yesterday,\n> and it turned out that this issue is nontrivial:\n> [...]\n> the best workaround that occured to me was adding -C/--chdir option to\n> main git binary, like one that Make accepts. This fixed my problem, I\n> paste the resulting patch below:\n\nI'm not completely opposed to -C, as it does match some other tools,\nbut it does seem superfluous with --git-dir and --work-tree. Which makes\nme feel like we are just papering over a bug instead of actually fixing\nit (and to be honest, I always wondered what the point of \"make -C\" was\nin the face of \"cd dir && make\").\n\nI'm not sure if the actual problem is related to the oft-discussed,\nunresolved work-tree startup woes, or is something much simpler to fix.\nI'll try to look closer later today.\n\nA few comments on your patch:\n\n> From 4461cd1be99772c93a83bcdfe6e6a86e71abaa35 Mon Sep 17 00:00:00 2001\n> From: Maciej Pasternacki \n> Date: Sun, 19 Oct 2008 01:33:49 +0200\n> Subject: [PATCH] Add command line option --chdir/-C to allow setting git process work directory.\n> \n> Signed-off-by: Maciej Pasternacki \n\nPlease follow the usual list conventions; this stuff should be the\nactual headers of your mail, not in the body of the message. And some of\nthe justification you gave above should be part of the commit message.\n\n> +\t\t} else if (!strcmp(cmd, \"-C\") || !strcmp(cmd, \"--chdir\")) {\n> + chdir((*argv)[1]);\n\nNo error detection and reporting? I think I would be quite happy for\n\"git -C /some/path clean -dx\" to bail out when it saw that it couldn't\nchange directory instead of just deleting the contents of wherever I\nhappened to be.\n\nAlso, the envchanged flag should probably be set, as for the git-dir and\nwork-tree options.\n\n-Peff\n"},{"id":"93428","messageId":"86685067-021C-4DC5-A462-AA6834208BDE@pasternacki.net","threadId":"15956","inReplyTo":"20081019131745.GA8643@coredump.intra.peff.net","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Maciej Pasternacki","fromEmail":"maciej@pasternacki.net","sentAt":"2008-10-19T13:47:04Z","receivedAt":"2008-10-19T13:47:04Z","isPatch":true,"sender":{"key":"maciej@pasternacki.net","avatar":"https://gravatar.com/avatar/6485c5851d08fb9492fd6b9528e10b730c82320a0665560401c417a5f9209773?d=mp&s=160"},"body":"\nOn 2008-10-19, at 15:17, Jeff King wrote:\n\n> On Sat, Oct 18, 2008 at 05:02:27PM -0700, Maciej Pasternacki wrote:\n>\n>> In my project cl-librarian, which is a layer built upon different\n>> version control systems, I need to run git pull, but start it from\n>> outside of work tree; however, pull needs to be in work tree (as in\n>> getcwd()) in order to update said work tree. --git-dir and\n>> --work-tree options don't work; I discussed it on #git yesterday,\n>> and it turned out that this issue is nontrivial:\n>> [...]\n>> the best workaround that occured to me was adding -C/--chdir option \n>> to\n>> main git binary, like one that Make accepts. This fixed my \n>> problem, I\n>> paste the resulting patch below:\n>\n> I'm not completely opposed to -C, as it does match some other tools,\n> but it does seem superfluous with --git-dir and --work-tree. Which \n> makes\n> me feel like we are just papering over a bug instead of actually \n> fixing\n> it (and to be honest, I always wondered what the point of \"make -C\" \n> was\n> in the face of \"cd dir && make\").\n\nThe point of make -C is exactly my usage pattern: invoking make from \nexternal program. I have seen, at least in Lisp (external-program) \nand Python (os.spawn, subprocess), libraries to safely and portably \nexecute external program by giving literal list of arguments (an easy \nto use wrapper to fork()+exec(); I don't know if such feature exists \nfor C). This allows me not to worry about quoting strange characters \nin pathnames (think injections, if just making it possible to use \"&\" \ncharacter in directory name is not good enough a reason). The \nequivalent of \"cd dir && make\" would be to use system() or invoke sh - \nc; both would require shell-quoting the directory pathname, and would \ncarry portability issues -- how do I know that shell on target system \nis actually called \"sh\" and it supports \"&&\"? At least Windows \nsystems would be problematic.\n\nThe -C option allows me to just specify the directory as it is, and \nchild process, after the fork, will take care of the chdir(). No \nquoting, no portability problems, injection-safety included.\n\nAs for -C being superfluous: --git-dir and --work-tree seem to support \nweird usage patterns (like work tree separate from git-dir), but it \nseems to me that --work-tree could be just made a synonym of -C, and \nit would behave as expected without creating chicken-and-egg problem \nthat doener on #git found (which I don't really understand, but I also \ncan't see what --work-tree allows that -C would not -- except creating \nmore fragility). I won't push on --work-tree and -C being \nfunctionally synonymous, since I don't know git well enough, it's just \nmy impression at the moment.\n\n> Please follow the usual list conventions; this stuff should be the\n> actual headers of your mail, not in the body of the message. And \n> some of\n> the justification you gave above should be part of the commit message.\n\nACK. That was how I understood instructions linked from git.or.cz, \nI'll paste message correctly for next version of the patch.\n\n>> +\t\t} else if (!strcmp(cmd, \"-C\") || !strcmp(cmd, \"--chdir\")) {\n>> + chdir((*argv)[1]);\n>\n> No error detection and reporting? I think I would be quite happy for\n> \"git -C /some/path clean -dx\" to bail out when it saw that it couldn't\n> change directory instead of just deleting the contents of wherever I\n> happened to be.\n\nOops. Looks like I'm spoiled by high-level languages that would \nautomatically catch and display an error. I'll prepare patch v2 today.\n\n> Also, the envchanged flag should probably be set, as for the git-dir \n> and\n> work-tree options.\n\nOK. I thought it means literally environment change, as in setenv().\n\nThank you for your comments, off to make v2 patch,\nMaciej.\n\n-- \n-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-\n"},{"id":"93426","messageId":"20081019141634.GA8997@coredump.intra.peff.net","threadId":"15956","inReplyTo":"86685067-021C-4DC5-A462-AA6834208BDE@pasternacki.net","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-19T14:16:34Z","receivedAt":"2008-10-19T14:16:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:\n\n> As for -C being superfluous: --git-dir and --work-tree seem to support \n> weird usage patterns (like work tree separate from git-dir), but it seems \n\nHmm. Yeah, thinking about it more, -C is not really superfluous with\nrespect to those options. You don't want to say \"here is the work-tree,\nand here is the git-dir\". You want to say \"find the work-tree and\ngit-dir for me using the usual rules, as if I were in this directory.\"\n\nSo you couldn't just say:\n\n git --work-tree=/chdir/path\n\nsince that would assume your current directory was the git-dir. You\nwould need:\n\n git --work-tree=/chdir/path --git-dir=/chdir/path/.git\n\nbut then you are overriding any usual lookup rules (e.g., somebody\nhaving set GIT_DIR in the environment).\n\nThough I am not clear from your original description if that is even\nwhat you want. It sounds like you might be doing:\n\n git -C /chdir/path --git-dir=/back/to/where/I/was\n\nin which case I think work-tree _is_ a better fit.\n\n> to me that --work-tree could be just made a synonym of -C, and it would \n> behave as expected without creating chicken-and-egg problem that doener on \n> #git found (which I don't really understand, but I also can't see what \n> --work-tree allows that -C would not -- except creating more fragility). \n\n--work-tree allows you say \"I'm _already_ in the git-dir, but please use\nthis other place for the work-tree\". So you can, for example, checkout\nfiles from a bare repository.\n\n>> Also, the envchanged flag should probably be set, as for the git-dir\n>> and work-tree options.\n>\n> OK. I thought it means literally environment change, as in setenv().\n\nIt is really used to tell the options parser for aliases that some\noptions which change the operating environment should not be used in an\nalias. I.e., something like:\n\n git config alias.foo \"--git-dir=/path/to/whatever log\"\n\nisn't allowed, because we have already done some work on setting up the\ngit-dir at this point. IMHO, this is a limitation of the current\napproach to setting up the environment, but fixing it would be\nnontrivial.\n\nI'm not 100% sure that doing a chdir should be disallowed in this\ninstance, but I suspect it would cause problems. I think it is better in\nthis instance to be conservative and disallow it in aliases.\n\n-Peff\n"},{"id":"93422","messageId":"81E9D278-4851-4B1E-BE7D-D8563CEDA6F9@pasternacki.net","threadId":"15956","inReplyTo":"20081019141634.GA8997@coredump.intra.peff.net","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Maciej Pasternacki","fromEmail":"maciej@pasternacki.net","sentAt":"2008-10-19T15:24:37Z","receivedAt":"2008-10-19T15:24:37Z","isPatch":true,"sender":{"key":"maciej@pasternacki.net","avatar":"https://gravatar.com/avatar/6485c5851d08fb9492fd6b9528e10b730c82320a0665560401c417a5f9209773?d=mp&s=160"},"body":"On 2008-10-19, at 16:16, Jeff King wrote:\n\n> Though I am not clear from your original description if that is even\n> what you want. It sounds like you might be doing:\n>\n> git -C /chdir/path --git-dir=/back/to/where/I/was\n>\n> in which case I think work-tree _is_ a better fit.\n\nNo. I have a regular \"git clone\"'d work tree inside some \"shelf\" \ndirectory containing many repos (not only from git), and I'd like to \npull changes into this work tree. As simple as \"cvs up\". But -- I \ndon't want to chdir() there myself, and I had no problem with cvs, svn \nand darcs (didn't do other VC systems yet). So, -C would do exactly \nwhat I need.\n\n>>> Also, the envchanged flag should probably be set, as for the git-dir\n>>> and work-tree options.\n>>\n>> OK. I thought it means literally environment change, as in setenv().\n>\n> It is really used to tell the options parser for aliases that some\n> options which change the operating environment should not be used in \n> an\n> alias. I.e., something like:\n>\n> git config alias.foo \"--git-dir=/path/to/whatever log\"\n>\n> isn't allowed, because we have already done some work on setting up \n> the\n> git-dir at this point. IMHO, this is a limitation of the current\n> approach to setting up the environment, but fixing it would be\n> nontrivial.\n>\n> I'm not 100% sure that doing a chdir should be disallowed in this\n> instance, but I suspect it would cause problems. I think it is \n> better in\n> this instance to be conservative and disallow it in aliases.\n\nIn this case, I think envchanged should not be set -- I would expect - \nC dir to work *exactly* like \"cd dir && git ...\", including \nconfiguration, environment variables and so on. OTOH, option like \"-- \nno-env\" may be useful in my case -- I want git to behave consistently \non users' machines, regardless of their configuration. This, however, \nis only a minor issue.\n\nRegards,\nMaciej.\n\n-- \n-><- Maciej Pasternacki -><- http://www.pasternacki.net/ -><-\n"},{"id":"93478","messageId":"7vr66b50gy.fsf@gitster.siamese.dyndns.org","threadId":"15956","inReplyTo":"20081019141634.GA8997@coredump.intra.peff.net","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-20T04:55:57Z","receivedAt":"2008-10-20T04:55:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:\n>\n>> As for -C being superfluous: --git-dir and --work-tree seem to support \n>> weird usage patterns (like work tree separate from git-dir), but it seems \n>\n> Hmm. Yeah, thinking about it more, -C is not really superfluous with\n> respect to those options. You don't want to say \"here is the work-tree,\n> and here is the git-dir\". You want to say \"find the work-tree and\n> git-dir for me using the usual rules, as if I were in this directory.\"\n\nI think that interpretation of -C, if the option existed, makes sense, but\nI do not understand why the tool that drives git refuses to chdir to the\nrepository for itself in the first place.\n\nThe only excuse I remember seeing in the thread was that \"make has '-C'\noption, so let's have it, because it is similar\", which does not justfiy\naddition of that option to git at all to me.\n\nWith \"make\", the -C option can be justified as a necessary tool to write a\nrecursive Makefile that can be sanely and easily processed without\nactually executing any commands (iow, imaging implementing \"make\" that\nallows you to write \"cd there && $(MAKE)\" in the toplevel Makefile and\ntells the users what would happen in \"there\" when run as \"make -n\").\n\nAnd even in \"make\" context, not all implementations have it. I think it\nis only GNU and fairly recent BSDs.\n"},{"id":"93481","messageId":"7vhc774ydr.fsf@gitster.siamese.dyndns.org","threadId":"15956","inReplyTo":"7vr66b50gy.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-20T05:41:04Z","receivedAt":"2008-10-20T05:41:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The only excuse I remember seeing in the thread was that \"make has '-C'\n> option, so let's have it, because it is similar\", which does not justfiy\n> addition of that option to git at all to me.\n\nJust after having said that \"make has it, so let's have it ourselves, too\"\nis a non-excuse to any feature bloat, one thing I could accept a patch to\nimitate what \"make\" does, especially if we are going to actually clean up\nthe startup sequence like we have discussed sometime ago to fix breakage\naround --work-tree, is to have VAR=VAL (e.g. \"make CFLAGS=-O2\") on the\ncommand line. We could use that syntax to allow configuration variables\nto be overridden, like so:\n\n\t$ git core.whitespace=cr-at-eol log -p master..next\n\nI wouldn't however suggest allowing the syntax to set environment\nvariables, like:\n\n\t$ git GIT_AUTHOR_NAME=\"A U Thor\" commit\n\nas this is something your shell lets you do easily, i.e:\n\n\t$ GIT_AUTHOR_NAME=\"A U Thor\" git commit\n\nBut overriding some configuration variables for a single command\ninvocation is not something you can do without actually editing the\nconfiguration file for some variables, so the former would be justified.\n"},{"id":"93484","messageId":"81b0412b0810192326n7ace9d4fjd8013cbe1872df22@mail.gmail.com","threadId":"15956","inReplyTo":"7vhc774ydr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-10-20T06:26:12Z","receivedAt":"2008-10-20T06:26:12Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2008/10/20 Junio C Hamano :\n> Junio C Hamano writes:\n> I wouldn't however suggest allowing the syntax to set environment\n> variables, like:\n>\n> $ git GIT_AUTHOR_NAME=\"A U Thor\" commit\n>\n> as this is something your shell lets you do easily, i.e:\n>\n> $ GIT_AUTHOR_NAME=\"A U Thor\" git commit\n>\n\nNo, someplace else it doesn't (yes, windows again).\nIt is mostly hard to do there, because the system shell is so\nprimitive, and installation of something sane (sh or env) is\nan additional (and hard to explain to windows zealots) hassle.\n\nAnd even in something like Perl it is hard: you cannot\nchange the environment just for the child process, you\nhave to change your own, run the process and change\nit back.\n\nSo, yes, I like your suggestion, but I'd like to _include_\nsetting all the Git's environment.\n"},{"id":"93516","messageId":"48FC8049.2080107@drmicha.warpmail.net","threadId":"15956","inReplyTo":"7vr66b50gy.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-20T12:57:45Z","receivedAt":"2008-10-20T12:57:45Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 20.10.2008 06:55:\n> Jeff King writes:\n> \n>> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:\n>>\n>>> As for -C being superfluous: --git-dir and --work-tree seem to support \n>>> weird usage patterns (like work tree separate from git-dir), but it seems \n>> Hmm. Yeah, thinking about it more, -C is not really superfluous with\n>> respect to those options. You don't want to say \"here is the work-tree,\n>> and here is the git-dir\". You want to say \"find the work-tree and\n>> git-dir for me using the usual rules, as if I were in this directory.\"\n> \n> I think that interpretation of -C, if the option existed, makes sense, but\n> I do not understand why the tool that drives git refuses to chdir to the\n> repository for itself in the first place.\n> \n> The only excuse I remember seeing in the thread was that \"make has '-C'\n> option, so let's have it, because it is similar\", which does not justfiy\n> addition of that option to git at all to me.\n\nI want to have '-j2' ;)\n\nSeriously:\n\ngit -C elsewhere command opts\n\nis shorther and more direct than\n\n(cd elsewhere && git command opts)\n\nwhich is the true equivalent, or\n\npushd elsewhere; git command opts; popd\n\nAnd much shorter than using --git-dir and --work-tree, which are\nsemi-broken right now.\n\nI just think it's very useful to be able to peek into a repo somewhere\nelse quickly; or for transferral of objects between unrelated objects\n(run rev-parse elsewhere etc.).\n\nMichael\n"},{"id":"93513","messageId":"fcaeb9bf0810200659p91acb1cj58be43d3ef1c3e15@mail.gmail.com","threadId":"15956","inReplyTo":"20081019131745.GA8643@coredump.intra.peff.net","subject":"Re: [PATCH] -C/--chdir command line option","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-10-20T13:59:46Z","receivedAt":"2008-10-20T13:59:46Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/19/08, Jeff King wrote:\n> I'm not sure if the actual problem is related to the oft-discussed,\n> unresolved work-tree startup woes, or is something much simpler to fix.\n> I'll try to look closer later today.\n\nI think all commands should be able to jump to worktree even if you\nare outside work-tree. git-pull and similar commands are easy because\nthey don't take pathnames. The way pathnames are handled in git does\nnot make it easy for outside current working directory, because if old\ncwd is outside worktree, the parameter \"prefix\" sent to those commands\nbecome \"../../blah/\", not a real prefix anymore. If a command expects\nan index pathname, then that prefix should be rejected. If they expect\na filesystem pathname, it can be used with care.\n-- \nDuy\n"}]}