Junio C Hamano venit, vidit, dixit 18.03.2011 08:25: > Carlos MartÃn Nieto <cmn@xxxxxxxx> 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 -- 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