On Tue, Dec 28, 2010 at 11:47:07AM -0800, Junio C Hamano wrote: > Carlo Marcelo Arenas Belon <carenas@xxxxxxxxxxxxxx> writes: > > > otherwise, comparison to validate against work tree will fail when > > the path includes a symlink and the name passed is not canonical. > > > > Signed-off-by: Carlo Marcelo Arenas Belon <carenas@xxxxxxxxxxxxxx> > > I take that "path" and "name passed" refer to the same thing (i.e. "path" > parameter) in the above. yes, and sorry for the cryptic description; you detailed below though this is triggered by the fact that when using an absolute path filename as a parameter detection for worktree is failing because it was normalized through make_absolute_path. > I think you are trying to handle the case where: > > - you give "/home/carenas/one" from the command line; > - $PWD is "/home/carenas"; and > - "/home/carenas" is a symlink to "/net/host/home/carenas" this will be a valid scenario, but the issue (with a different use case) was reported in (which I missed to refer to when running git send-email): http://thread.gmane.org/gmane.comp.version-control.git/164212 > and the scan-from-the-beginning-of-string check done between > "/home/carenas/one" and the return value of get_git_work_tree() which > presumably is "/net/host/home/carenas" disagrees. I wonder if a more > correct solution might be to help get_git_work_tree() to match the notion > of where the repository and its worktree are to the idea of where the user > thinks they are, i.e. not "/net/host/home/carenas" but "/home/carenas", a > bit better? are you suggesting symlinks would be left untouched at least during resolution for work_dir?, why is even necesary to resolve the links for other users of that function? Carlo -- 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