Re: Difficulty adding a symbolic link, part 3

>> From: Duy Nguyen <pclouds@gmail.com>
>
>> > Can someone give me advice on what this code *should* do?
>>
>> It does as the function name says: given cwd, a prefix (i.e. a
>> relative path with no ".." components) and a path relative to
>> cwd+prefix, convert 'path' to something relative to cwd. In the
>> simplest case, prepending the prefix to 'path' is enough. cwd is also
>> get_git_work_tree().
>>
>> I agree with you that this code should not resolve anything in the
>> components after 'cwd', after rebasing the path to 'cwd' (not just the
>> final component). Not sure how to do it correctly though because we do
>> need to resolve symlinks before cwd. Maybe a new variant of real_path
>> that stops at 'cwd'?
>>
>> We may also have problems with resolve symlinks before cwd when 'path'
>> is relative, as normalize_path_copy() does not resolve symlinks. We
>> just found out emacs has this bug [1] but did not realize we also have
>> one :-P.
>
> Thanks for the detailed information.  It seems to me that the minimum
> needed change is that the handling of relative and absolute paths
> should be made consistent.

>
>> [1] http://thread.gmane.org/gmane.comp.version-control.git/231268
>
> That problem isn't so much a matter of not resolving symlinks but
> rather the question of what ".." means.  In the case shown in that
> message, the current directory *is* {topdir}/z/b, but it was entered
> with "cd {topdir}/b" -- and the shell records the latter as the value
> of $PWD.  (Actually, the bash shell can handle symbolic-linked
> directories *either* way, depending on whether it is given the "-P"
> option.)
>
> When Emacs is given the file name "../a/file", does the ".." mean to
> go up one directory *textually* in the pathspec based on $PWD
>
> "{topdir}/b/../a/file" -> "{topdir}/a/file" (which does not exist)
>
> or according to the directory linkage on the disk (where the ".."
> entry in the current directory goes to the directory named {topdir}/z,
> which does contain a file a/file.  It looks like Emacs uses the first
> method.
>
> The decision of which implementation to use depends on the semantics
> you *want*.  As I noted, bash allows the user to choose *either*
> interpretation, which shows that both semantics are considered valid
> (by some people).