Matthias Lederhofer <matled@xxxxxxx> writes:
> 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
... and do the rev-parse test with *and* *without* $GIT_WORK_DIR
or $GIT_DIR/workdir to make sure there won't be any regressions.
> 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.
Silently ignoring would leave the user who misconfigured it by
mistake.
By the way, why should it be $GIT_DIR/workdir when it appears
everybody is putting things in $GIT_DIR/config? Shouldn't it be
something like:
[core]
worktree = "/path/to/the/working/tree"
And more importantly, why nobody mentioned the above so far?
Maybe it is a sign that nobody is interested in this new
feature?
-
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