Re: [PATCH] Name make_*_path functions more accurately

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mar 18, 2011, 08:06 UTC
Message-ID: <4D83128D.6020206@drmicha.warpmail.net>
In-Reply-To: <7vipvgyjnl.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 18.03.2011 08:25:

Show 24 quoted lines

> Carlos Martín Nieto <cmn@elego.de> writes:
> 
>> Rename the make_*_path functions so it's clearer what they do, in
>> particlar make clear what the differnce between make_absolute_path and
>> make_nonrelative_path is by renaming them real_path and absolute_path
>> respectively. make_relative_path has an understandable name and is
>> renamed to relative_path to maintain the name convention.
> 
> The approach taken by this patch is a sound one, and I like it.  The
> change does not reuse any existing name for different purpose, which means
> there is little chance of this change interacting other topics that may be
> in flight that introduce new call sites to these renamed functions in a
> funny way.  A (semantic) mismerge or misapplication of the patch will be
> found by the compiler.
> 
> For example, the version of setup.c this patch is based on the version
> before 05f08e4 (Merge branch 'cb/setup', 2011-02-09) was merged, and the
> merge introduced a new call site to make_absolute_path().  A few callsites
> to make_nonrelative_path() in wrapper.c were introduced at 70ec868 (Merge
> branch 'ae/better-template-failure-report', 2011-02-09), and this patch
> does not touch them.
> 
> As the result, the patch cleanly applies textually, but the resulting code
> does not compile, and it is a good thing ;-).

...because the "diff --color-words" for this version of the patch makes it clear you only have to rerun

sed -e 's/make_absolute_path/real_path/g'

etc. on the affected files to resolve this "merge-compile conflict".

Just pointing it out for those who wonder why I pestered Carlos to bring the patch into this form, and why Junio started to like failed builds. Also, I need to make-up for making Junio explain my recent RFD :)

Cheers, Michael