Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes: > First of all, core.worktree should not matter because GIT_DIR has not > been set (No don't trust core.worktree documentation, it's equivalent > to --work-tree in "man git"). You need to set GIT_DIR (or --git-dir). > That's a bug I'm working on. > > Then, yes, rebase should be updated to use worktree even if it's > outside cwd. I'm not sure how to do it properly in git-rebase.sh > though. The requirement "require_work_tree" can be loosen a bit. Thanks, I can confirm that the following works: () have /abs/path/to/wheregitis/.git () have /abs/path/to/wherefilesare () export GIT_DIR=/abs/path/to/wheregitis/.git () DO NOT have core.worktree (or related items) set () cd /abs/path/to/wherefilesare () git rebase master This is a bit more dangerous than running git commands in GIT_DIR and pointing core.worktree elsewhere, since I could make the error of (1) leaving GIT_DIR unintentionally still set when doing something else, or (2) running git commands outside the (unmarked) root of the worktree. Still... it works. BTW, the impetus for this is a big integrated cross-compilation build system that has a nasty habit of deleting and re-creating a chroot environment containing the directory structures including the work tree. If the ".git" dir is at the "normal" place "inside" the work tree, it gets deleted along with all the work I have done. Not good, which is why I want to keep the ".git" somewhere else that's safe. Solutions to this: (preferred) core.worktree pointing into worktree elsewhere, run all git commands from GIT_DIR. Would be great if rebase worked under these circumstances. (best fallback) no core.worktree, export GIT_DIR pointing elsewhere, run all git commands from unmarked root of worktree. (complex) A complex scenario pushing and pulling stuff between a git repo inside the worktree and another git clone outside the worktree. (implementation dependent) Having the ".git" dir inside the worktree be a symbolic link to a dir somewhere outside the work tree. Keeps the actual ".git" contents safe from deletion. Works so far, but this is Tampering With The Implementation in a way that is likely to fail down the road somewhere, e.g., if an internal script does cd to the GIT_DIR, then cd relative to that to try to get back into somewhere else in the work tree. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html