> From: Duy Nguyen <pclo...@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).

Dale
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to