{"thread":{"id":"25609","subject":"rebase not honoring core.worktree pointing elsewhere","startedAt":"2010-11-01T17:22:05Z","lastAt":"2010-11-04T14:20:05Z","messageCount":10,"participants":["Paul Drews","Sverre Rabbelier","Nguyen Thai Ngoc Duy","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"154935","messageId":"loom.20101101T182113-378@post.gmane.org","threadId":"25609","inReplyTo":null,"subject":"rebase not honoring core.worktree pointing elsewhere","fromName":"Paul Drews","fromEmail":"paul.drews@intel.com","sentAt":"2010-11-01T17:22:05Z","receivedAt":"2010-11-01T17:22:05Z","isPatch":false,"sender":{"key":"paul.drews@intel.com","avatar":null},"body":"Hello,\n\nI'm observing an unexpected error from \"git rebase\" run from the directory\ncontaining the \".git\" directory:\n\n$ git --version\n\ngit version 1.7.3.GIT\n(includes up to commit ca2090 from git repository at\nhttp://www.kernel.org/pub/scm/git/git.git)\n\n$ mkdir wherefilesare\n$ mkdir wheregitis\n$ cd wherefilesare\n$ echo \"Here is a line from the original\" > myfile.txt\n$ cd ../wheregitis\n$ git init\n$ git config core.worktree /absolute/path/to/wherefilesare/\n$ git add .\n$ git commit\n$ git branch mybranch\n$ git checkout mybranch\n$ vim ../wherefilesare/myfile.txt \n$ git add .\n$ git commit\n$ git checkout master\n$ vim ../wherefilesare/myfile.txt \n$ git add .\n$ git commit\n$ git checkout mybranch\n$ git rebase master\n\nfatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.\n\nSince I'm in the directory containing \".git\" at this point, the \".git\" directory\nand the worktree can be unambiguously found. Other commands besides \"git\nrebase\" work. I would expect \"git rebase\" to work as well. Is this a bug or an\nunreasonable expectation on my part?\n"},{"id":"154937","messageId":"AANLkTimdJgobR_C2cCA7oLHc2Yr9YsSobqsMMueN=XAE@mail.gmail.com","threadId":"25609","inReplyTo":"loom.20101101T182113-378@post.gmane.org","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-11-01T17:38:44Z","receivedAt":"2010-11-01T17:38:44Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"[+Nguyễn Thái Ngọc Duy, who is currently working on improving/fixing\nhow git handles worktree detection]\n\nOn Mon, Nov 1, 2010 at 18:22, Paul Drews wrote:\n> I'm observing an unexpected error from \"git rebase\" run from the directory\n> containing the \".git\" directory:\n>\n> $ git --version\n>\n> git version 1.7.3.GIT\n> (includes up to commit ca2090 from git repository at\n> http://www.kernel.org/pub/scm/git/git.git)\n>\n> $ mkdir wherefilesare\n> $ mkdir wheregitis\n> $ cd wherefilesare\n> $ echo \"Here is a line from the original\" > myfile.txt\n> $ cd ../wheregitis\n> $ git init\n> $ git config core.worktree /absolute/path/to/wherefilesare/\n> $ git add .\n> $ git commit\n> $ git branch mybranch\n> $ git checkout mybranch\n> $ vim ../wherefilesare/myfile.txt\n> $ git add .\n> $ git commit\n> $ git checkout master\n> $ vim ../wherefilesare/myfile.txt\n> $ git add .\n> $ git commit\n> $ git checkout mybranch\n> $ git rebase master\n>\n> fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.\n>\n> Since I'm in the directory containing \".git\" at this point, the \".git\" directory\n> and the worktree can be unambiguously found.  Other commands besides \"git\n> rebase\" work.  I would expect \"git rebase\" to work as well.  Is this a bug or an\n> unreasonable expectation on my part?\n\nSounds like a bug.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"154949","messageId":"AANLkTi=ejRcnz+83zc2Z-6etUGMsBSw1FFUY0JNFRFGB@mail.gmail.com","threadId":"25609","inReplyTo":"loom.20101101T182113-378@post.gmane.org","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-02T00:11:16Z","receivedAt":"2010-11-02T00:11:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Nov 2, 2010 at 12:22 AM, Paul Drews wrote:\n> Hello,\n>\n> I'm observing an unexpected error from \"git rebase\" run from the directory\n> containing the \".git\" directory:\n>\n> $ git --version\n>\n> git version 1.7.3.GIT\n> (includes up to commit ca2090 from git repository at\n> http://www.kernel.org/pub/scm/git/git.git)\n>\n> $ mkdir wherefilesare\n> $ mkdir wheregitis\n> $ cd wherefilesare\n> $ echo \"Here is a line from the original\" > myfile.txt\n> $ cd ../wheregitis\n> $ git init\n> $ git config core.worktree /absolute/path/to/wherefilesare/\n> $ git add .\n> $ git commit\n> $ git branch mybranch\n> $ git checkout mybranch\n> $ vim ../wherefilesare/myfile.txt\n> $ git add .\n> $ git commit\n> $ git checkout master\n> $ vim ../wherefilesare/myfile.txt\n> $ git add .\n> $ git commit\n> $ git checkout mybranch\n> $ git rebase master\n>\n> fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.\n>\n> Since I'm in the directory containing \".git\" at this point, the \".git\" directory\n> and the worktree can be unambiguously found.  Other commands besides \"git\n> rebase\" work.  I would expect \"git rebase\" to work as well.  Is this a bug or an\n> unreasonable expectation on my part?\n\nFirst of all, core.worktree should not matter because GIT_DIR has not\nbeen set (No don't trust core.worktree documentation, it's equivalent\nto --work-tree in \"man git\"). You need to set GIT_DIR (or --git-dir).\nThat's a bug I'm working on.\n\nThen, yes, rebase should be updated to use worktree even if it's\noutside cwd. I'm not sure how to do it properly in git-rebase.sh\nthough. The requirement \"require_work_tree\" can be loosen a bit.\n-- \nDuy\n"},{"id":"154951","messageId":"7v1v7434h8.fsf@alter.siamese.dyndns.org","threadId":"25609","inReplyTo":"AANLkTi=ejRcnz+83zc2Z-6etUGMsBSw1FFUY0JNFRFGB@mail.gmail.com","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-11-02T01:21:23Z","receivedAt":"2010-11-02T01:21:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> Then, yes, rebase should be updated to use worktree even if it's\n> outside cwd. I'm not sure how to do it properly in git-rebase.sh\n> though. The requirement \"require_work_tree\" can be loosen a bit.\n\nrequire-work-tree traditionally meant \"you must be inside the working\ntree, you could be in a subdirectory of it\", but as long as the command is\nabout the whole tree operation (which rebase is) and takes no pathname\nrelative to the $(cwd) as an argument (which rebase does not), there is no\nstrong reason why you should be _inside_ the working tree. For such\ncommands, require-work-tree should mean \"you must have a working tree, and\nmake it known where it is to git\", nothing more.\n"},{"id":"154987","messageId":"loom.20101102T165800-486@post.gmane.org","threadId":"25609","inReplyTo":"AANLkTi=ejRcnz+83zc2Z-6etUGMsBSw1FFUY0JNFRFGB@mail.gmail.com","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Paul Drews","fromEmail":"paul.drews@intel.com","sentAt":"2010-11-02T16:26:49Z","receivedAt":"2010-11-02T16:26:49Z","isPatch":false,"sender":{"key":"paul.drews@intel.com","avatar":null},"body":"Nguyen Thai Ngoc Duy gmail.com> writes:\n\n> First of all, core.worktree should not matter because GIT_DIR has not\n> been set (No don't trust core.worktree documentation, it's equivalent\n> to --work-tree in \"man git\"). You need to set GIT_DIR (or --git-dir).\n> That's a bug I'm working on.\n> \n> Then, yes, rebase should be updated to use worktree even if it's\n> outside cwd. I'm not sure how to do it properly in git-rebase.sh\n> though. The requirement \"require_work_tree\" can be loosen a bit.\n\nThanks,\nI can confirm that the following works:\n\n() have /abs/path/to/wheregitis/.git\n() have /abs/path/to/wherefilesare\n() export GIT_DIR=/abs/path/to/wheregitis/.git\n() DO NOT have core.worktree (or related items) set\n() cd /abs/path/to/wherefilesare\n() git rebase master\n\nThis is a bit more dangerous than running git commands in GIT_DIR and pointing\ncore.worktree elsewhere, since I could make the error of (1) leaving GIT_DIR\nunintentionally still set when doing something else, or (2) running git commands\noutside the (unmarked) root of the worktree. Still... it works.\n\nBTW, the impetus for this is a big integrated cross-compilation build system\nthat has a nasty habit of deleting and re-creating a chroot environment\ncontaining the directory structures including the work tree. If the \".git\"\ndir is at the \"normal\" place \"inside\" the work tree, it gets deleted along\nwith all the work I have done. Not good, which is why I want to keep the\n\".git\" somewhere else that's safe. Solutions to this:\n\n(preferred) core.worktree pointing into worktree elsewhere, run all git\ncommands from GIT_DIR. Would be great if rebase worked under these\ncircumstances.\n\n(best fallback) no core.worktree, export GIT_DIR pointing elsewhere, run all\ngit commands from unmarked root of worktree.\n\n(complex) A complex scenario pushing and pulling stuff between a git repo\ninside the worktree and another git clone outside the worktree.\n\n(implementation dependent) Having the \".git\" dir inside the worktree be a\nsymbolic link to a dir somewhere outside the work tree. Keeps the actual \".git\"\ncontents safe from deletion. Works so far, but this is Tampering With The\nImplementation in a way that is likely to fail down the road somewhere,\ne.g., if an internal script does cd to the GIT_DIR, then cd relative to\nthat to try to get back into somewhere else in the work tree.\n"},{"id":"155014","messageId":"AANLkTi=T5kHfgNOpOtCDCoq7epEgwUrVayaUCbf35dSU@mail.gmail.com","threadId":"25609","inReplyTo":"loom.20101102T165800-486@post.gmane.org","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-03T00:13:58Z","receivedAt":"2010-11-03T00:13:58Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Nov 2, 2010 at 11:26 PM, Paul Drews wrote:\n> BTW, the impetus for this is a big integrated cross-compilation build system\n> that has a nasty habit of deleting and re-creating a chroot environment\n> containing the directory structures including the work tree.  If the \".git\"\n> dir is at the \"normal\" place \"inside\" the work tree, it gets deleted along\n> with all the work I have done.  Not good, which is why I want to keep the\n> \".git\" somewhere else that's safe.  Solutions to this:\n>\n> (preferred) core.worktree pointing into worktree elsewhere, run all git\n> commands from GIT_DIR.  Would be great if rebase worked under these\n> circumstances.\n>\n> (best fallback) no core.worktree, export GIT_DIR pointing elsewhere, run all\n> git commands from unmarked root of worktree.\n>\n> (complex) A complex scenario pushing and pulling stuff between a git repo\n> inside the worktree and another git clone outside the worktree.\n>\n> (implementation dependent) Having the \".git\" dir inside the worktree be a\n> symbolic link to a dir somewhere outside the work tree.  Keeps the actual \".git\"\n> contents safe from deletion.  Works so far, but this is Tampering With The\n> Implementation in a way that is likely to fail down the road somewhere,\n> e.g., if an internal script does cd to the GIT_DIR, then cd relative to\n> that to try to get back into somewhere else in the work tree.\n\nAnother one: create a .git file with this line and put it in worktree's topdir\n\ngitdir: /path/to/real/git.dir\n\nSee gitrepository-layout.txt.\n-- \nDuy\n"},{"id":"155048","messageId":"loom.20101103T162424-483@post.gmane.org","threadId":"25609","inReplyTo":"AANLkTi=T5kHfgNOpOtCDCoq7epEgwUrVayaUCbf35dSU@mail.gmail.com","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Paul Drews","fromEmail":"paul.drews@intel.com","sentAt":"2010-11-03T15:41:06Z","receivedAt":"2010-11-03T15:41:06Z","isPatch":false,"sender":{"key":"paul.drews@intel.com","avatar":null},"body":"Nguyen Thai Ngoc Duy gmail.com> writes:\n\n> > (implementation dependent) Having the \".git\" dir inside the worktree be a\n> > symbolic link to a dir somewhere outside the work tree.  Keeps the actual\n> > \".git\"\n> > contents safe from deletion.  Works so far, but this is Tampering With The\n> > Implementation in a way that is likely to fail down the road somewhere,\n> > e.g., if an internal script does cd to the GIT_DIR, then cd relative to\n> > that to try to get back into somewhere else in the work tree.\n> \n> Another one: create a .git file with this line and put it in worktree's\n> topdir\n> \n> gitdir: /path/to/real/git.dir\n> \n> See gitrepository-layout.txt.\n\nOoh! That would be my favorite, since it's a documented legal usage.\nUnfortunately, although the rebase scenario works that way a local\n\"git clone\" doesn't work:\n\n# git clone /abs/path/to/proj\nCloning into proj...\nfatal: failed to open '/abs/path/to/proj/objects': No such file or directory\n# git clone /abs/path/to/proj/\nCloning into proj...\nfatal: failed to open '/abs/path/to/proj//objects': No such file or directory\n# git --version\ngit version 1.7.3.GIT\n\nweird\n"},{"id":"155050","messageId":"AANLkTi=UxD0cNvFK0RctCq=idfQV4VH+sNoOO2PLT2sh@mail.gmail.com","threadId":"25609","inReplyTo":"loom.20101103T162424-483@post.gmane.org","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-03T15:52:46Z","receivedAt":"2010-11-03T15:52:46Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Nov 3, 2010 at 10:41 PM, Paul Drews wrote:\n>> Another one: create a .git file with this line and put it in worktree's\n>> topdir\n>>\n>> gitdir: /path/to/real/git.dir\n>>\n>> See gitrepository-layout.txt.\n>\n> Ooh!  That would be my favorite, since it's a documented legal usage.\n> Unfortunately, although the rebase scenario works that way a local\n> \"git clone\" doesn't work:\n>\n> # git clone /abs/path/to/proj\n> Cloning into proj...\n> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory\n> # git clone /abs/path/to/proj/\n> Cloning into proj...\n> fatal: failed to open '/abs/path/to/proj//objects': No such file or directory\n> # git --version\n> git version 1.7.3.GIT\n\n\"git clone\" needs to learn about .git file. Thanks for pointing it out.\n-- \nDuy\n"},{"id":"155051","messageId":"20101103161311.GA12934@burratino","threadId":"25609","inReplyTo":"loom.20101103T162424-483@post.gmane.org","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-03T16:13:12Z","receivedAt":"2010-11-03T16:13:12Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Paul Drews wrote:\n> Nguyen Thai Ngoc Duy gmail.com> writes:\n\n>> Another one: create a .git file with this line and put it in worktree's\n>> topdir\n>> \n>> gitdir: /path/to/real/git.dir\n>> \n>> See gitrepository-layout.txt.\n>\n> Ooh! That would be my favorite, since it's a documented legal usage.\n\nBy the way, .git symlinks have been historically supported and are not\nlikely to break, either. Maybe gitrepository-layout should grow to\ninclude a section on the repository search.\n\n> Unfortunately, although the rebase scenario works that way a local\n> \"git clone\" doesn't work:\n> \n> # git clone /abs/path/to/proj\n> Cloning into proj...\n> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory\n\nenter_repo() never learned .git file support, though I see no reason it should\nbe hard to add.\n\nPointers:\n\n - v1.5.6-rc0~93^2~3 (Add platform-independent .git \"symlink\",\n 2008-02-20)\n\n - v0.99.9l^2 (daemon.c and path.enter_repo(): revamp path validation,\n 2005-12-03)\n\nThe precise return value from enter_repo() is currently only used by\n\"git daemon\", to handle directory arguments as in\n\n\tgit daemon -- /srv/git\n\nso returning a fictional path like\n\n\t/abs/path/to/proj/.git\n\nmight work ok. :)\n\nGood catch.\n"},{"id":"155168","messageId":"AANLkTi=DJMLdHD2t2znS4eA57LnTfcPhLUaPbJktE7NB@mail.gmail.com","threadId":"25609","inReplyTo":"20101103161311.GA12934@burratino","subject":"Re: rebase not honoring core.worktree pointing elsewhere","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-11-04T14:20:05Z","receivedAt":"2010-11-04T14:20:05Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Nov 3, 2010 at 11:13 PM, Jonathan Nieder wrote:\n> Paul Drews wrote:\n>> Nguyen Thai Ngoc Duy gmail.com> writes:\n>\n>>> Another one: create a .git file with this line and put it in worktree's\n>>> topdir\n>>>\n>>> gitdir: /path/to/real/git.dir\n>>>\n>>> See gitrepository-layout.txt.\n>>\n>> Ooh!  That would be my favorite, since it's a documented legal usage.\n>\n> By the way, .git symlinks have been historically supported and are not\n> likely to break, either.  Maybe gitrepository-layout should grow to\n> include a section on the repository search.\n>\n>> Unfortunately, although the rebase scenario works that way a local\n>> \"git clone\" doesn't work:\n>>\n>> # git clone /abs/path/to/proj\n>> Cloning into proj...\n>> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory\n>\n> enter_repo() never learned .git file support, though I see no reason it should\n> be hard to add.\n\nAlso get_repo_path(). By the way if you work on this, please move\nenter_repo() to setup.c. Keeping it close to setup_* functions may\nincrease the chance that it also gets fixed along with setup_*.\n\nAnother thing. \"git init\" should probably learn to create .git file.\nEach time I use .git file I have to look at man page^W^Wsource code\nagain to know its syntax.\n-- \nDuy\n"}]}