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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

[I know, blast from the past...]

On Mon, 13 Feb 2017, Junio C Hamano wrote:

> Marc Strapetz <marc.strapetz@syntevo.com> writes:
> 
> > 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>.

So... I finally had a look at this, and while I agree that the quoted
version is better, I also agree that the backslash is mistaken for a
continuation character (which is not even allowed in section headers).

A quick test with my `empty-config-section` patch series shows that it
addresses this issue. A quick bisec confirms that the patch with the
online "git_config_set: make use of the config parser's event stream" is
responsible for this fix.

At first, I was puzzled by this, because I expected `git remote rename` to
be backed by the `git_config_copy_or_rename_section_in_file()` function
(which my patch series does not touch).

But then I looked at the code of the `mv()` function in builtin/remote.c
and it uses `git_config_set_multivar()` and `git_config_set()`. And those
functions were indeed touched (and fixed) by above-mentioned commit.

Ciao,
Johannes