Re: git rebase does not understand --work-tree

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jul 14, 2010, 12:54 UTC
Message-ID: <4C3DB396.2040109@drmicha.warpmail.net>
In-Reply-To: <AANLkTimnk6tflv9ZZCydlX1la35GjsRfvjgTk44uDFbO@mail.gmail.com>

Alexander Gladysh venit, vidit, dixit 14.07.2010 11:04:

Show 12 quoted lines

> Hi, list!
> 
> $ git --version
> git version 1.7.1.1
> 
> I often use --work-tree and --git-dir to avoid doing cd in my scripts.
> 
> However, I've found that git rebase does not understand --work-tree
> option (see test below). Is this fixable?
> 
> Thanks,
> Alexander.

In your case, omitting --work-tree almost works, as well as using "--work-tree=." (note the dot). "Almost" meaning that rebase does not complain. It just doesn't find the work-tree.

I think the main problem here is a problem with relative work trees.

First of all, work tree is meant to be relative to (the repo specified by) GIT_DIR, but that's not what "git rev-parse --top-level" is doing. Experimenting with relative --git-dir and --work-tree here shows that it's relative to cwd.

Second, several git shell commands (such as rebase) cd to the toplevel of the repo only after checking whether we are in a work tree already. This is brain dead and should be cured by the upcoming patch. With that, absolute paths for work-tree will work with rebase.

Third, git's setup code exports GIT_DIR as an absolute path but GIT_WORK_TREE as a relative path. Together with the fact that the work tree is interpreted relative to the current directory, this is doomed for failure when you cd around - as rebase does automatically!

I'm not sure I find time for the latter point, but until then the patch enables you to work with absolute paths.

Michael