From: Carlos Martín Nieto <cmn@elego.de>
Date: Wed, 16 Mar 2011 15:08:28 GMT
Subject: Re: [PATCH 1/3] make_absolute_path: Don't try to copy a string to itself
Message-ID: <1300288108.7214.37.camel@bee.lab.cmartin.tk>
In-Reply-To: <AANLkTimvVd8VrAvcuT9Qww07-Gg1JtyA=+8nr4EeU0_D@mail.gmail.com>

On mié, 2011-03-16 at 21:04 +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Mar 16, 2011 at 12:02 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Carlos Martín Nieto <cmn@elego.de> writes:
> >
> >> On mar, 2011-03-15 at 12:59 +0100, Carlos Martín Nieto wrote:
> >>> On lun, 2011-03-14 at 15:58 -0700, Junio C Hamano wrote:
> >>> > Carlos Martín Nieto <cmn@elego.de> writes:
> >> [...]
> >>> >
> >>> > >  There is however the extra functionality the function offers, namely
> >>> > > resolving links. It might be good to split it into two functions so each
> >>> > > caller can specify what it wants.
> >>> >
> >>> > Probably.
> >>>
> >>>  With the changes mentioned earlier, if you want an absolute pathname,
> >>> you'd call absolute_path/make_nonrelative_path and if you want to make
> >>> sure you have the real path of the target file, you'd use real_path just
> >>> as you'd use realpath on a sane system, with
> >>
> >>  ... a comment on the functions and maybe some documentation in
> >> Documentation/techncal, as it doesn't seem to exist yet.
> >
> > We probably should involve Nguyễn in this thread as his fingers are
> > everywhere on the codepaths related to setup.
> 
> Thanks, my attempt to fix up setup code leaves more traces that I expect.
> 
> Splitting functions is fine, but is there any use of
> absolute_path/make_nonrelative_path alone? Most setup code uses
> make_absolute_path() for $GIT_{DIR,WORK_TREE}. For GIT_DIR, a
> resolved/normalized path is preferred. For GIT_WORK_TREE, I'm not
> sure. I tend to treat it the same way as GIT_DIR, but you guys may
> have a special case.

 There only real use for absolute_path/make_nonrelative_path would be
for paths that are written to disk (as we should respect the user's path
preferences). For paths we never write out, real_path/make_absolute_path
makes sense.

 The way I want to split it up is to have real_path use a simplistic
approach, and use a resolve_link function if it needs to. From logging
what paths make_absolute_path is called with, all I could find were
directories ("." is used very often as well). This should make real_path
very easy to understand. I'll start a new thread with the renaming
patches and then split up the function.