[RFC 0/2] refactor relative_path in path.c

[Jiang Xin]

2013/5/15 Junio C Hamano gits...@pobox.com:
 Jiang Xin worldhello@gmail.com writes:

 +/*
 + * Give path as relative to prefix.
 + *
 + * This function is a combination of path_relative (in quote.c) and
 + * relative_path (in path.c)
 + */
 +static const char *path_relative(const char *in, const char *prefix)
 +{
 +...

 Hmph.  Is it possible to reuse the public one (in path.c) here and
 in quote.c, perhaps after enhancing it a bit to serve needs of the
 callers of two existing ones and the new callers of this one?


These two patches enhance relative_path() in path.c, so that function
relative_path() will return real relative path, not a path strip off
the prefix.

The 2nd patch is a bit aggressive, it refactor all related functions,
remove unnecessary arguments: len and/or prefix_len.

Please review them. They will be prerequisites for the interactive
git-clean patch series.

Jiang Xin (2):
  path.c: refactor relative_path(), not only strip prefix
  quote.c: remove path_relative, use relative_path instead

 builtin/clean.c| 18 +--
 builtin/grep.c |  4 +--
 builtin/ls-files.c | 13 
 path.c | 94 ++
 quote.c| 71 +++--
 quote.h|  7 ++--
 wt-status.c| 17 +-
 7 files changed, 107 insertions(+), 117 deletions(-)

-- 
1.8.3.rc1.404.ga32c147

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/2] refactor relative_path in path.c

[Junio C Hamano]

Jiang Xin worldhello@gmail.com writes:

 These two patches enhance relative_path() in path.c, so that function
 relative_path() will return real relative path, not a path strip off
 the prefix.

 The 2nd patch is a bit aggressive, it refactor all related functions,
 remove unnecessary arguments: len and/or prefix_len.

I did not particularly find the second one aggressive; it would
have been much more pleasant to review if the drop unused 'len'
part were made into a separate patch [3/2] as a follow-up, though.

It is a bit sad that relative_path() in [1/2] uses a single static
and fixed sized buffer.  How is the new implementation making sure
the expanded result does not overflow the buf[]?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html