Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git-compat-util: move convert_slashes from compat/mingw.h and rename it #1699

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mohit-marathe
Copy link

@mohit-marathe mohit-marathe commented Mar 18, 2024

Hi all,

This series aims to complete a #leftoverbits: https://lore.kernel.org/
git/[email protected]/ by moving convert_slashes() to
git-compat-util.h and renaming it to change_path_separators().

I appreciate your review and feedback on this patch series.

Best regards,
Mohit Marathe

cc: Josh Steadmon [email protected]

This patch migrates the `convert_slashes` function to `git-compat-
util.h` and renames it to `change_path_separators`.

Signed-off-by: Mohit Marathe <[email protected]>
This patch replaces the code, that changes the path separators,
with the already existing function `change_path_separators()`

Signed-off-by: Mohit Marathe <[email protected]>
@mohit-marathe
Copy link
Author

/preview

Copy link

gitgitgadget bot commented Mar 18, 2024

Preview email sent as [email protected]

@mohit-marathe
Copy link
Author

/submit

Copy link

gitgitgadget bot commented Mar 18, 2024

Submitted as [email protected]

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1699/mohit-marathe/convert-slashes-v1

To fetch this version to local tag pr-1699/mohit-marathe/convert-slashes-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1699/mohit-marathe/convert-slashes-v1

@@ -58,7 +58,7 @@ static void get_root_part(struct strbuf *resolved, struct strbuf *remaining)
strbuf_reset(resolved);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Mohit Marathe via GitGitGadget" <[email protected]> writes:

> From: Mohit Marathe <[email protected]>
>
> 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.

@@ -52,9 +52,7 @@ static const char *make_relative(const char *location)
prefix_len = len - needle_len;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Mohit Marathe via GitGitGadget" <[email protected]> writes:

> From: Mohit Marathe <[email protected]>
>
> This patch replaces the code, that changes the path separators,
> with the already existing function `change_path_separators()`

Aside from that the name change_path_separators() needs to be
updated, using it here means that the helper cannot become a NO-OP
on platforms where we do not have to change backslashes we read from
the system to forward slashes.  So if we really wanted to use it
here, and update the other existing callers in the main code to help
them lose the ugly "#if WINDOWS" conditional compilation, we would
need two helper functions, perhaps one that is used here that is
identical to the current convert_slashes(), and the other one used
to clean-up the callsites in [1/2] to also remove the conditional
compilation.

Even if we were to make it public, I am not sure if compat-util is
the right place, though.  It is not a kitchen sink.

In any case, perhaps we want to do something like this in a header,
...

	static inline void bs_to_forward_slash_in_place(char *path)
	{
		...
	}
	#ifdef GIT_WINDOWS_NATIVE
	#define normalize_slashes_in_place(path) bs_to_forward_slash_in_place(path)
	#else
	#define normalize_slashes_in_place(path) do { ; /* nothing */ } while (0)
	#endif

... and then use the "normalize" one to lose "#ifdef" in the callers
[1/2] touches, while "bs_to_forward_slash" one here.

I am not convinced if it is worth doing only for this single test,
though.

> @@ -88,9 +86,8 @@ static const char *make_relative(const char *location)
>  
>  	/* convert backslashes to forward slashes */
>  	strlcpy(buf, location + prefix_len, sizeof(buf));
> -	for (p = buf; *p; p++)
> -		if (*p == '\\')
> -			*p = '/';
> +	p = buf;
> +	change_path_separators(p);
>  	return buf;
>  }

@mohit-marathe
Copy link
Author

Hi @dscho! I made this patch after seeing your comment here: https://lore.kernel.org/git/[email protected]/
I have to write a proper commit description but I don't understand why do we have to move convert_slashes() to git-compat-util.h.
Sorry, I should've asked this earlier, before submitting the patch.

@dscho
Copy link
Member

dscho commented Mar 24, 2024

why do we have to move convert_slashes() to git-compat-util.h.

It is only available on Windows so far, thanks to being defined in compat/mingw.h. In https://lore.kernel.org/git/[email protected]/ we were discussing a patch for code running on all platforms, not just Windows.

@@ -52,9 +52,7 @@ static const char *make_relative(const char *location)
prefix_len = len - needle_len;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Josh Steadmon wrote (reply to this):

On 2024.03.18 12:47, Mohit Marathe via GitGitGadget wrote:
> From: Mohit Marathe <[email protected]>
> 
> This patch replaces the code, that changes the path separators,
> with the already existing function `change_path_separators()`
> 
> Signed-off-by: Mohit Marathe <[email protected]>
> ---
>  t/unit-tests/test-lib.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/t/unit-tests/test-lib.c b/t/unit-tests/test-lib.c
> index 66d6980ffbe..b0e26263046 100644
> --- a/t/unit-tests/test-lib.c
> +++ b/t/unit-tests/test-lib.c
> @@ -52,9 +52,7 @@ static const char *make_relative(const char *location)
>  		prefix_len = len - needle_len;
>  		if (prefix[prefix_len + 1] == '/') {
>  			/* Oh, we're not Windows */
> -			for (size_t i = 0; i < needle_len; i++)
> -				if (needle[i] == '\\')
> -					needle[i] = '/';
> +			change_path_separators(&needle[0]);

Why not just:
change_path_separators(needle);
?

>  			need_bs_to_fs = 0;
>  		} else {
>  			need_bs_to_fs = 1;
> @@ -88,9 +86,8 @@ static const char *make_relative(const char *location)
>  
>  	/* convert backslashes to forward slashes */
>  	strlcpy(buf, location + prefix_len, sizeof(buf));
> -	for (p = buf; *p; p++)
> -		if (*p == '\\')
> -			*p = '/';
> +	p = buf;
> +	change_path_separators(p);

And here, why not:
change_path_separators(buf)
?

>  	return buf;
>  }
>  
> -- 
> gitgitgadget
> 

Copy link

gitgitgadget bot commented Apr 11, 2024

User Josh Steadmon <[email protected]> has been added to the cc: list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants