Re: [PATCH 2/2] worktree: provide better prefix to go back to original cwd

[Junio C Hamano <gitster@pobox.com>]

pclouds@gmail.com writes:

> From: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>
> When both GIT_DIR and GIT_WORK_TREE are set, if cwd is outside
> worktree, prefix (the one passed to every builtin commands) will be
> set to NULL, which means "user stays at worktree topdir", but cwd is
> not moved to worktree topdir.

Well, NULL traditionally meant "_if_ the cwd is inside the working tree,
it is at the top", not "stays at worktree topdir" if you started from
elsewhere.

And when cwd is inside the working tree, we do want to feed paths given
from the command line after adding the prefix, so that we will see the
paths relative to the cwd after we do cd-to-topdir.

Obviously when you run git command that requires you to be in a working
tree from outside the working tree, relative or full paths would not make
any difference.  The command should simply fail.

I suspect that you are introducing a new semantics on top of that
traditional semantics; if so, you may want to state it more clearly.

For example:

    When you run git command that requires you to be in a working tree
    from outside the working tree, the command should simply fail.

    When GIT_WORK_TREE is in use, however, it could be argued that we do
    not necessarily have to be in anywhere in the working tree to perform
    a whole-tree operation.  Instead, we could just say the operation
    always runs as if the command was started at the root level of the
    working tree.

    To support this new mode of operation, however, prefix needs to be
    adjusted to allow the program, after running chdir(2) to the root of
    the working tree, to refer to non-absolute paths originally given from
    the command line as relative to the original cwd.  This patch adds a
    mechanism to support that.

I have a queasy feeling about the idea of the second paragraph above,
though.

If the original cwd is inside GIT_WORK_TREE, limiting ourselves inside
prefix naturally limits the operation to the subdirectory we started from
(if the original cwd is at GIT_WORK_TREE, that would make it a whole-tree
operation).  A natural extension of this idea to limit the operation to
the part of the subtree of the working tree we started from is to refuse
to work in the case where the original cwd is outside GIT_WORK_TREE (the
current implementation of GIT_WORK_TREE may or may not correctly implement
it, though---I never use it myself).

Futzing with the prefix that is not a prefix to reach into the working
tree from sideways may make the relative paths given from the command line
mean something to the current implementation, but it doesn't change the
fundamental fact that you are introducing a funny special case where your
cwd does _not_ mean anything with respect to which part of the working
tree should be affected.

> Some commands may want "path in repository" and "path in file system"
> to be identical. Moreover, output from commands in such situations are
> relative to worktree topdir (because prefix is NULL), not what users
> expect. It's just confusing.

My gut feeling is that this is probably made more confusing, not less,
with the change.  Perhaps we should instead make sure this fails?

    $ cd /srv/git/git.git
    $ export GIT_DIR=$(pwd)/.git GIT_WORK_TREE=$(pwd)
    $ cd /var/tmp ;# no git stuff there
    $ git status