Re: [PATCH 1/2] git-compat-util: migrate `convert_slashes()` from compat/mingw.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Mohit Marathe via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> From: Mohit Marathe <mohitmarathe@xxxxxxxxx>
>
> 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.

> 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.

> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux