Marc Strapetz [off-list ref] 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>.
Hi,
[I know, blast from the past...]
On Mon, 13 Feb 2017, Junio C Hamano wrote:
Marc Strapetz [off-list ref] writes:
quoted
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