Re: [PATCH] setup: translate symlinks in filename when using absolute paths

On Tue, Dec 28, 2010 at 11:47:07AM -0800, Junio C Hamano wrote:

Carlo Marcelo Arenas Belon [off-list ref] writes:

quoted

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 <redacted>

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