Re: rebase not honoring core.worktree pointing elsewhere

[Paul Drews <paul.drews@intel.com>]

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.