Re: [PATCH v2 1/3] path: use forward slashes in XDG config on Windows

From: Delilah Ashley Wu <delilahwu@linux.microsoft.com>
Date: Sep 10, 2026, 04:48 UTC
Message-ID: <aqIvJhLLcCSnyaL4-delilahwu@linux.microsoft.com>
In-Reply-To: <xmqqecfkhify.fsf@gitster.g>

Thanks for the reviews! I'm still working through the feedback for v3.

On Wed, Aug 26, 2026 at 10:58:57AM +1000, Junio C Hamano wrote:

> Is this "force forwared slashes to Windows users" a required part of
> XDG/HOME global fix?  If not, please leave it out of the topic. [...]
> Again, I do not see it explained why this change has to be part of
> this series in the proposed log message, so...?

Sorry, I forgot to explain in the log message that this change is supposed to supplement the `--show-origin` tests added in patch 3 (config: read global scope via config_sequence). Without it, the `--show-origin` would output a path with mixed slashes on Windows:

    file:"C:\\Users\\delilah/.config/git/config"    xdg.foo=bar

The tests expect paths containing only forward slashes. So patch 3 modifies `t1300-config.sh` assertions to look like this:

    echo "file:$HOME/.config/git/config    xdg.config=xdg" >expect
    git config list --global --show-origin >actual
    test_cmp expect actual

where `$HOME` has been normalised to contain forward slashes only, as seen at `t1300-config.sh:2179`, which was introduced in 45bf329 (t1300: fix the new --show-origin tests on Windows):

    HOME="$(pwd)" # convert to Windows path

Show 7 quoted lines

> Even if it is a good idea to always force forward slashes to Windows
> users (I have no strong opinions on the topic), and if it is very
> unlikely to break existing Windows users (I do not have any clue if
> that would be the case or not, as I do not do Windows), we would
> want to make sure if we can get the same effect without sprinkling
> "#ifdef" in the platform agnostic part of the codebase like "path.c"
> file.

I followed an existing usage of `#ifdef GIT_WINDOWS_NATIVE` and `convert_slashes()` in `path.c`, but if it's no longer allowed in the platform agnostic part, we could do the slash conversion elsewhere. This assumes we want to keep converting the slashes, but we should reconsider from your points raised below.

> Where would the slash in "ret" that is passed to convert_slashes()
> function come from?  If they come from environment variables like
> XDG_CONFIG_HOME and HOME, that is end-user's preference and we have
> no business forcing them which forms of slashes to use.

The slash in `ret` would come from the environment variables, so perhaps we should not modify the slashes in them at all. Instead, I could drop this patch and change the tests in patch 3 to export a `XDG_CONFIG_HOME` value containing only forward slashes. This would satisfy the assumption that paths in the tests will contain only forward slashes. What do you think?

Thanks! Delilah =)