rebase not honoring core.worktree pointing elsewhere

rebase not honoring core.worktree pointing elsewhere

[Paul Drews]

Hello,

I'm observing an unexpected error from "git rebase" run from the directory
containing the ".git" directory:

$ git --version

git version 1.7.3.GIT
(includes up to commit ca2090 from git repository at
http://www.kernel.org/pub/scm/git/git.git)

$ mkdir wherefilesare
$ mkdir wheregitis
$ cd wherefilesare
$ echo "Here is a line from the original" > myfile.txt
$ cd ../wheregitis
$ git init
$ git config core.worktree /absolute/path/to/wherefilesare/
$ git add .
$ git commit
$ git branch mybranch
$ git checkout mybranch
$ vim ../wherefilesare/myfile.txt 
$ git add .
$ git commit
$ git checkout master
$ vim ../wherefilesare/myfile.txt 
$ git add .
$ git commit
$ git checkout mybranch
$ git rebase master

fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.

Since I'm in the directory containing ".git" at this point, the ".git" directory
and the worktree can be unambiguously found.  Other commands besides "git
rebase" work.  I would expect "git rebase" to work as well.  Is this a bug or an
unreasonable expectation on my part?

Re: rebase not honoring core.worktree pointing elsewhere

[Sverre Rabbelier]

[+Nguyễn Thái Ngọc Duy, who is currently working on improving/fixing
how git handles worktree detection]

On Mon, Nov 1, 2010 at 18:22, Paul Drews <paul.drews@intel.com> wrote:
> I'm observing an unexpected error from "git rebase" run from the directory
> containing the ".git" directory:
>
> $ git --version
>
> git version 1.7.3.GIT
> (includes up to commit ca2090 from git repository at
> http://www.kernel.org/pub/scm/git/git.git)
>
> $ mkdir wherefilesare
> $ mkdir wheregitis
> $ cd wherefilesare
> $ echo "Here is a line from the original" > myfile.txt
> $ cd ../wheregitis
> $ git init
> $ git config core.worktree /absolute/path/to/wherefilesare/
> $ git add .
> $ git commit
> $ git branch mybranch
> $ git checkout mybranch
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout master
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout mybranch
> $ git rebase master
>
> fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.
>
> Since I'm in the directory containing ".git" at this point, the ".git" directory
> and the worktree can be unambiguously found.  Other commands besides "git
> rebase" work.  I would expect "git rebase" to work as well.  Is this a bug or an
> unreasonable expectation on my part?

Sounds like a bug.

-- 
Cheers,

Sverre Rabbelier

Re: rebase not honoring core.worktree pointing elsewhere

[Nguyen Thai Ngoc Duy]

On Tue, Nov 2, 2010 at 12:22 AM, Paul Drews <paul.drews@intel.com> wrote:
> Hello,
>
> I'm observing an unexpected error from "git rebase" run from the directory
> containing the ".git" directory:
>
> $ git --version
>
> git version 1.7.3.GIT
> (includes up to commit ca2090 from git repository at
> http://www.kernel.org/pub/scm/git/git.git)
>
> $ mkdir wherefilesare
> $ mkdir wheregitis
> $ cd wherefilesare
> $ echo "Here is a line from the original" > myfile.txt
> $ cd ../wheregitis
> $ git init
> $ git config core.worktree /absolute/path/to/wherefilesare/
> $ git add .
> $ git commit
> $ git branch mybranch
> $ git checkout mybranch
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout master
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout mybranch
> $ git rebase master
>
> fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.
>
> Since I'm in the directory containing ".git" at this point, the ".git" directory
> and the worktree can be unambiguously found.  Other commands besides "git
> rebase" work.  I would expect "git rebase" to work as well.  Is this a bug or an
> unreasonable expectation on my part?

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.
-- 
Duy

Re: rebase not honoring core.worktree pointing elsewhere

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> 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.

require-work-tree traditionally meant "you must be inside the working
tree, you could be in a subdirectory of it", but as long as the command is
about the whole tree operation (which rebase is) and takes no pathname
relative to the $(cwd) as an argument (which rebase does not), there is no
strong reason why you should be _inside_ the working tree.  For such
commands, require-work-tree should mean "you must have a working tree, and
make it known where it is to git", nothing more.

Re: rebase not honoring core.worktree pointing elsewhere

[Paul Drews]

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.

Re: rebase not honoring core.worktree pointing elsewhere

[Nguyen Thai Ngoc Duy]

On Tue, Nov 2, 2010 at 11:26 PM, Paul Drews <paul.drews@intel.com> wrote:
> 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.

Another one: create a .git file with this line and put it in worktree's topdir

gitdir: /path/to/real/git.dir

See gitrepository-layout.txt.
-- 
Duy

Re: rebase not honoring core.worktree pointing elsewhere

[Paul Drews]

Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:

> > (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.
> 
> Another one: create a .git file with this line and put it in worktree's
> topdir
> 
> gitdir: /path/to/real/git.dir
> 
> See gitrepository-layout.txt.

Ooh!  That would be my favorite, since it's a documented legal usage.
Unfortunately, although the rebase scenario works that way a local
"git clone" doesn't work:

# git clone /abs/path/to/proj
Cloning into proj...
fatal: failed to open '/abs/path/to/proj/objects': No such file or directory
# git clone /abs/path/to/proj/
Cloning into proj...
fatal: failed to open '/abs/path/to/proj//objects': No such file or directory
# git --version
git version 1.7.3.GIT

weird

Re: rebase not honoring core.worktree pointing elsewhere

[Nguyen Thai Ngoc Duy]

On Wed, Nov 3, 2010 at 10:41 PM, Paul Drews <paul.drews@intel.com> wrote:
>> Another one: create a .git file with this line and put it in worktree's
>> topdir
>>
>> gitdir: /path/to/real/git.dir
>>
>> See gitrepository-layout.txt.
>
> Ooh!  That would be my favorite, since it's a documented legal usage.
> Unfortunately, although the rebase scenario works that way a local
> "git clone" doesn't work:
>
> # git clone /abs/path/to/proj
> Cloning into proj...
> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory
> # git clone /abs/path/to/proj/
> Cloning into proj...
> fatal: failed to open '/abs/path/to/proj//objects': No such file or directory
> # git --version
> git version 1.7.3.GIT

"git clone" needs to learn about .git file. Thanks for pointing it out.
-- 
Duy

Re: rebase not honoring core.worktree pointing elsewhere

[Jonathan Nieder]

Paul Drews wrote:
> Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:

>> Another one: create a .git file with this line and put it in worktree's
>> topdir
>> 
>> gitdir: /path/to/real/git.dir
>> 
>> See gitrepository-layout.txt.
>
> Ooh!  That would be my favorite, since it's a documented legal usage.

By the way, .git symlinks have been historically supported and are not
likely to break, either.  Maybe gitrepository-layout should grow to
include a section on the repository search.

> Unfortunately, although the rebase scenario works that way a local
> "git clone" doesn't work:
> 
> # git clone /abs/path/to/proj
> Cloning into proj...
> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory

enter_repo() never learned .git file support, though I see no reason it should
be hard to add.

Pointers:

 - v1.5.6-rc0~93^2~3 (Add platform-independent .git "symlink",
   2008-02-20)

 - v0.99.9l^2 (daemon.c and path.enter_repo(): revamp path validation,
   2005-12-03)

The precise return value from enter_repo() is currently only used by
"git daemon", to handle directory arguments as in

	git daemon -- /srv/git

so returning a fictional path like

	/abs/path/to/proj/.git

might work ok. :)

Good catch.

Re: rebase not honoring core.worktree pointing elsewhere

[Nguyen Thai Ngoc Duy]

On Wed, Nov 3, 2010 at 11:13 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Paul Drews wrote:
>> Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
>>> Another one: create a .git file with this line and put it in worktree's
>>> topdir
>>>
>>> gitdir: /path/to/real/git.dir
>>>
>>> See gitrepository-layout.txt.
>>
>> Ooh!  That would be my favorite, since it's a documented legal usage.
>
> By the way, .git symlinks have been historically supported and are not
> likely to break, either.  Maybe gitrepository-layout should grow to
> include a section on the repository search.
>
>> Unfortunately, although the rebase scenario works that way a local
>> "git clone" doesn't work:
>>
>> # git clone /abs/path/to/proj
>> Cloning into proj...
>> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory
>
> enter_repo() never learned .git file support, though I see no reason it should
> be hard to add.

Also get_repo_path(). By the way if you work on this, please move
enter_repo() to setup.c. Keeping it close to setup_* functions may
increase the chance that it also gets fixed along with setup_*.

Another thing. "git init" should probably learn to create .git file.
Each time I use .git file I have to look at man page^W^Wsource code
again to know its syntax.
-- 
Duy