Re: [PATCH 1/2] git-compat-util: migrate `convert_slashes()` from compat/mingw.h
"Mohit Marathe via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Mohit Marathe <mohitmarathe@proton.me>
>
> This patch migrates the `convert_slashes` function to `git-compat-
> util.h` and renames it to `change_path_separators`.
That is something a reader can tell from looking at what the patch does. What they cannot read from the diff is why the author of the patch thought it was a good idea and that is what we want to see here.
Show 11 quoted lines
> diff --git a/abspath.c b/abspath.c
> index 1202cde23db..ea35e2c05ce 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -58,7 +58,7 @@ static void get_root_part(struct strbuf *resolved, struct strbuf *remaining)
> strbuf_reset(resolved);
> strbuf_add(resolved, remaining->buf, offset);
> #ifdef GIT_WINDOWS_NATIVE
> - convert_slashes(resolved->buf);
> + change_path_separators(resolved->buf);
> #endif
In the context of "#ifdef GIT_WINDOWS_NATIVE..#endif" conditional compilation, the name convert_slashes() may have made some sense, i.e. "on this system, we get a path with the kind of slash that is not suitable to be used in Git, so we correct it to the other kind of slash". But neither it, or change_path_separators(), as a name of public function makes much sense. The direction of the change is totally unclear.
"normalize" may be a verb that has some connotation which direction the conversion is going, but still, without knowing why this change is being made (not the name change, but the part that makes it public), I cannot offer much better candidates for its name.
Show 31 quoted lines
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 7c2a6538e5a..3db90c09295 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -1309,6 +1309,13 @@ static inline int strtol_i(char const *s, int base, int *result)
> return 0;
> }
>
> +static inline void change_path_separators(char *path)
> +{
> + for (; *path; path++)
> + if (*path == '\\')
> + *path = '/';
> +}
> +
> void git_stable_qsort(void *base, size_t nmemb, size_t size,
> int(*compar)(const void *, const void *));
> #ifdef INTERNAL_QSORT
> diff --git a/path.c b/path.c
> index 8bb223c92c9..cd7c88ffa0d 100644
> --- a/path.c
> +++ b/path.c
> @@ -758,7 +758,7 @@ char *interpolate_path(const char *path, int real_home)
> else
> strbuf_addstr(&user_path, home);
> #ifdef GIT_WINDOWS_NATIVE
> - convert_slashes(user_path.buf);
> + change_path_separators(user_path.buf);
> #endif
> } else {
> struct passwd *pw = getpw_str(username, username_len);If the idea were that "here we know that the path came from reading filesystem and on platforms that use backslashes as path separators, we need to normalize them into slashes before the path is usable in Git", then I might understand if a change were more like:
* Introduce normalize_path_separators_in_place(char *) that is a
NOOP by default, but does the backslash->slash conversion ONLY on
platforms that require it (i.e. Windows).
* Lose "#ifdef GIT_WINDOWS_NATIVE" and corresponding "#endif", and
call that normalize thing unconditionally, which gets optimized
away on most systems other then where it is required.
That way, the affected .c files would become somewhat easier to follow without ugly conditional compilation.
But with the proposed patch lacking any explanation why the author thought it was a good idea, the above is just my wild guess.
Mohit Marathe via GitGitGadget
