Re: What's cooking in git.git (topics)

From: Matthias Lederhofer <matled@gmx.net>
Date: Mar 13, 2007, 17:43 UTC
Message-ID: <20070313174304.GA2540@moooo.ath.cx>
In-Reply-To: <7vps7dle8j.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 7 quoted lines

> * ml/workdir (Sun Mar 11 22:29:06 2007 +0100) 3 commits
>  - use $GIT_DIR/workdir as working directory with $GIT_DIR
>  - introduce GIT_WORK_DIR environment variable
>  - rev-parse: --is-bare-repository option
> 
> Not in 'next' yet, but I think this one is ready to be tested.
> We need testsuite for it before that happens, though.

Will you apply the git-init patch too?

I did not write any tests yet, but I can try.

Here is what I thought about:

check that --work-dir overrides $GIT_WORK_DIR and both override $GIT_DIR/workdir.

use a correct and an invalid path for:
    $GIT_DIR/workdir:
        file containing a relative and an absolute path
        symlink pointing to an invalid path, a directory, a file
        test a symlink to something else (e.g. device, fifo, ..) too?
        directory
    $GIT_WORK_DIR: relative and absolute path
    and test what git does with git-rev-parse
            --is-bare-repository
            --show-prefix
            --show-cdup

test git rev-parse --is-inside-git-dir

A symlink pointing to an invalid path is currently handled as if there is no $GIT_DIR/workdir at all because stat returns ENOENT. Is this ok or should git complain like it does for an invalid path when $GIT_DIR/workdir is a file? We could also decide to ignore all invalid workdir settings and handle this the same as being outside the workdir.