> From: Duy Nguyen <pclouds@xxxxxxxxx> > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html