Re: [PATCH/RFC 1/4] cleanup_path: force forward slashes on Windows
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 19, 2025, 17:47 UTC
- Message-ID
- <xmqq7bvldidv.fsf@gitster.g>
- In-Reply-To
- <c8df6a042b9e971f392b2fd2d09a9c3c655dbceb.1760058849.git.gitgitgadget@gmail.com>
"Delilah Ashley Wu via GitGitGadget" <gitgitgadget@gmail.com> writes:
> All existing callers of > `cleanup_path()` pass `char *` anyways, so this change is compatible.
Not just compatible ;-). If there is a caller that wants cleanup_path() not to munge what it passes, this change will introduce a bug for them. Have you made sure that none of these callers mind that backslashes are converted into forward slashes?
> The next patch, config: test home and xdg files in `list --global`, will > assert that the XDG config path uses forward slashes.
The path to the leaf-level blobs is always slash separated in the index, a tree object sorts an entry that points at a subtree as if its path component has terminating slash, etc., and only when these paths are externalized, they are converted to filesystem dependent hierarchy separator (by system call like creat(2) even on platforms like Windows whose filesystem uses backslashes as the pathname separator). Canonicalizing end-user supplied path early at a central place does make sense.
Show 9 quoted lines
> -static const char *cleanup_path(const char *path)
> +static char *cleanup_path(char *path)
> {
> /* Clean it up */
> - if (skip_prefix(path, "./", &path)) {
> + if (skip_prefix(path, "./", (const char **)&path))
> while (*path == '/')
> path++;
> - }Hmph, the need for cast is a bit annoying, but more importantly, why don't we have to worry about leading ".\\\\" instead of ".////"? Shouldn't we be stripping backslashes the same way on Windows?
> +#ifdef GIT_WINDOWS_NATIVE > + convert_slashes(path); > +#endif
In other words, why do it here, not _before_ the loop that says "If the path begins with dot (i.e. the thing is relative to the current directory) followed by a directory separator, remove it together with any extra directory separators that come immediately after it"?
> return path; > }