On Thu, Aug 1, 2013 at 10:00 PM, Dale R. Worley <worley@xxxxxxxxxxxx> wrote: >> 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. Agreed. > >> [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). We pass paths around, the semantics must be one that others expect, not what we want. For one, the kernel seems to resolve symlinks first, then "..". We use chdir() and getcwd() provided by the kernel. We need to agree with it on ".." semantics. -- 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