Re: git remote rename problem with trailing \\ for remote.url config entries (on Windows)

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2017, 18:47 UTC
Message-ID: <xmqqo9y6dj1s.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <da730b21-58ae-bfa8-705f-7669c0f56764@syntevo.com>

Marc Strapetz <marc.strapetz@syntevo.com> writes:

Show 23 quoted lines

> One of our users has just reported that:
>
> $ git remote rename origin origin2
>
> will turn following remote entry:
>
> [remote "origin"]
> 	url = c:\\repo\\
> 	fetch = +refs/heads/*:refs/remotes/origin/*
>
> into following entry for which the url is skipped:
>
> [remote "origin2"]
> [remote "origin2"]
> 	fetch = +refs/heads/*:refs/remotes/origin2/*
>
> I understand that this is caused by the trailing \\ and it's easy to
> fix, but 'git push' and 'git pull' work properly with such URLs and a
>
> $ git clone c:\repo\
>
> will even result in the problematic remote-entry. So I guess some kind
> of validation could be helpful.

If you change the original definition of the "origin" to

        [remote "origin"]
               url = "c:\\repo\\"
               fetch = +refs/heads/*:refs/remotes/origin/*

or

        [remote "origin"]
               url = c:\\repo\\ # ends with bs
               fetch = +refs/heads/*:refs/remotes/origin/*

it seems to give me a better result. I didn't dig to determine where things go wrong in "remote rename", and it is possible that the problem is isolated to that command, or the same problem exists with any value that ends with a backslash. If the latter, "git clone" and anything that writes to configuration such a value needs to be taught about this glitch and learn a workaround, I would think.

Dscho Cc'ed, not for Windows expertise, but as somebody who has done a lot in <config.c>.