On Fri, Apr 14, 2017 at 4:29 AM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, Apr 12, 2017 at 08:11:22PM +0700, Duy Nguyen wrote:
>
>> On Wed, Apr 12, 2017 at 8:01 PM, Jeff King <peff@xxxxxxxx> wrote:
>> > I dunno. Maybe I am missing some subtle case, but it's not clear to me
>> > what the user would be trying to do by having git stay in the original
>> > directory.
>>
>> Not sure if it really happens. But if we jump from worktree is inside
>> original cwd and we have to jump to worktree, we set empty prefix, not
>> "../../../" one. So we can't refer back to files relative to original
>> cwd with prefix. I was kinda hoping "super prefix" would solve it, but
>> that one seems designed specifically for submodules.
>
> Ah, right. I think the issue is that "prefix" really serves two uses.
> For things like command-line arguments, we use to find the original path
> after we've moved. But we also use it for "where in the working tree
> are we".
>
> So with an out-of-tree cwd, we'd want to set the first one to the real
> path ("../../whatever" or even just an absolute path), but the second
> one would probably be empty (i.e., just pretend that we started from the
> top-level).
>
> But that would require first refactoring all of the cmd_* functions to
> handle those prefixes separately.
Yeah. I probably shouldn't start another series until all others of
mine settle. But if anyone is changing cmd_*, I suggest we take this
opportunity to pass "struct struct startup_info *" in the as the only
option. argv/argv could be stored there as well. And you can add
"cwd_prefix" to present that "../../whatever" (I would avoid the name
"super prefix" until things settle), or just keep the original "cwd"
in there and let people do whatever they want with it.
--
Duy