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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 7, 2010 at 12:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> pclouds@xxxxxxxxx writes:
>
>> From: Nguyán ThÃi Ngác Duy <pclouds@xxxxxxxxx>
>>
>> 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.

Yes. The better semantics _when_ cwd is outside worktree.

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

I tend to think that as we go up to worktree's root, prefix is shorten
and the operation area is widen. When cwd is at worktree's, we operate
on full worktree. If it goes up one level higher, the operation area
remains full worktree (but not everything under cwd because cwd now
can have non-worktree directories).

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

It would mean full worktree is affected. But not full cwd. In other
words, in set theory, it's a union of cwd and worktree.

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

Err.. you did not mean bare repo, did you?

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

I think it used to fail some time ago. Though I see nothing wrong if
that command works. And it'd be better if it outputs relative to
/var/tmp rather than /srv/git/git.git. I don't use this a lot but
sometimes I export GIT_DIR/GIT_WORK_TREE, cd around then do "git add
/srv/git/git.git/blah". To me, it should work. I may stand outside
worktree, but I give input inside worktree.
-- 
Duy
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]