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

pclouds@gmail.com writes:

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.

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