Push to repository in a shared folder doesn't work (regression from 2.10.2) #979
Milestone
Comments
|
While I agree that this is a bug, it looks as if it is made unnecessarily hard for Git. Why not simply call git push 'c:/Projects/Master/client' master --force |
|
I actially have a repo on a remote machine into which I cannot push with Git 2.11.0. I just verified that the problem exists even for a repo on localhost so that you could easily reproduce it. |
|
What does |
|
I also note that the message (IIUC) is from the remote side
I appreciate that it is localhost, but there is a shift of reponsibility there that may be part of the cause. Maybe the 'remote' code is mis-processing the path, especially as it has gone via the file:// protocol with it's special processing - see 'git clone --local'. (notes are via the 'urls.txt' documentation file). You could check that a direct path works properly (or not). |
|
Push through local paths works properly: |
|
Push into shared folder doesn't work even after successful push via local path (the remote repo has all the required objects because of previous push but the objects are not referenced at the moment). |
|
After downgrade to 2.10.2 push to the same shared folder works properly: |
|
MCVE: |
|
The same push with Git 2.10.2: |
|
Have you tried using the TRACE environment variables to see what (e.g. parameters) is being passed at each stage of the process. https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables The variables that look suitable are: I'm not sure how to make the 'remote' side be verbose for you as localhost. for full verbosity try this suggestion http://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems#comment57144190_17344517 You've probably seen https://public-inbox.org/git/20161204080914.GB2415@tb-raspi/T/#ma86b5372d4c78fadbd4977d5b2d010adf39f3f86 |
|
I'm having the same issue here's the trace for it: Combined: |
|
Same for me: My remote is configures as follows
(git version 2.10.2.windows.1)
|
|
Same bug here - unable to push to a Windows UNC share. (2.11.0 on x64 Win7). Push works fine on 2.10.2. |
|
Same bug here. Downgraded to 2.10.2 and it works now |
|
Similar Issue (downgraded to 2.10.2) I'm running into a odd problem that has only started I have a Windows network drive with several repositories. One of these The only ways I've found to temporary fix it on 2.11.0 are:
And, after I try pushing new commits back to the network drive, I run into the Other posts I checked: I have Windows write and read permission for everything in the remote repository. I tried the following commands on local and remote prior to pushing and experienced the same http://stackoverflow.com/a/18196948/7274513 I also tried removing the following from the home folder's .gitconfig. |
dscho
added a commit
to dscho/git
that referenced
this issue
Dec 23, 2016
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: git-for-windows#979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to git-for-windows/build-extra
that referenced
this issue
Dec 23, 2016
The regression of v2.11.0 where Git could no longer push to shared folders via UNC paths [is fixed](git-for-windows/git#979). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git
that referenced
this issue
Dec 23, 2016
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: git-for-windows#979 This regression was fixed in 7814fbe (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
fengguang
pushed a commit
to 0day-ci/git
that referenced
this issue
Dec 23, 2016
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: git-for-windows#979 This regression was fixed in 7814fbe (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitster
pushed a commit
to git/git
that referenced
this issue
Dec 23, 2016
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: git-for-windows#979 This regression was fixed in 7814fbe (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
dscho
added a commit
to dscho/git
that referenced
this issue
Jan 2, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: git-for-windows#979 This regression was fixed in 7814fbe (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
1 task
|
I think https://github.com/git-for-windows/git/releases/tag/v2.11.1.windows-prerelease.1 includes the fix. |
gitster
pushed a commit
to git/git
that referenced
this issue
Jan 8, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does, as reported here: git-for-windows#979 This regression was fixed in 7814fbe (normalize_path_copy(): fix pushing to //server/share/dir on Windows, 2016-12-14). Let's make sure that it does not regress again, by introducing a test that uses so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
Tested and confirmed that v2.11.1.windows-prerelease.1 does fix this issue. |
dscho
added a commit
that referenced
this issue
Jan 11, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Jan 11, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
v2.11.1.windows-prerelease.1 work for me too. |
dscho
added a commit
that referenced
this issue
Jan 18, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Jan 18, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Jan 18, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Jan 18, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Jan 18, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Jan 18, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
that referenced
this issue
Jan 25, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Jan 25, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git
that referenced
this issue
Feb 1, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: git-for-windows#979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Feb 1, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes git-for-windows#979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Feb 2, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Feb 2, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Feb 2, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-for-windows-ci
pushed a commit
that referenced
this issue
Feb 2, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
that referenced
this issue
Feb 3, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: #979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
that referenced
this issue
Feb 3, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes #979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
added a commit
to dscho/git
that referenced
this issue
Feb 21, 2017
On Windows, there are "UNC paths" to access network (AKA shared) folders, of the form \\server\sharename\directory. This provides a convenient way for Windows developers to share their Git repositories without having to have a dedicated server. Git for Windows v2.11.0 introduced a regression where pushing to said UNC paths no longer works, although fetching and cloning still does. Demonstrate what is the problem, using so-called "administrative shares": disk volumes are automatically shared under certain circumstances, e.g. the C: drive is shared as \\localhost\c$. The test needs to be skipped if the current directory is inaccessible via said administrative share, of course. Original-report: git-for-windows#979 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
dscho
pushed a commit
to dscho/git
that referenced
this issue
Feb 21, 2017
normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir. The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path. Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component(). This fixes git-for-windows#979 Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
I'm experiencing a similar issue. I have a PC and a Laptop, both running Cygwin on Windows 10. I use Git to keep certain files on them synchronized. They're both using Git version 2.12.2. lylez@dell-laptop /cygdrive/c/users/lylez/documents/budget lylez@dell-laptop /cygdrive/c/users/lylez/documents/budget lylez@dell-laptop /cygdrive/c/users/lylez/documents/budget lylez@dell-laptop /cygdrive/c/users/lylez/documents/budget This used to work until I upgraded Git. |
@lylez00 are you 100% sure that you run Cygwin Git here? I assume you are... in this case, the Git mailing list and/or the Cygwin mailing list is probably a more appropriate venue to report the bug: this is the Git for Windows project, which has little in common with the Cygwin Git project. |
|
Did it occured to anyone that "file:////" is an invalid URL? |
|
That's a tricky one: int mingw_offset_1st_component(const char *path) even in cygwin. And please, (to repeat Dscho) if you are using cygwin, please send this to the Git mailing list . |
|
Since Cygwin strive to provide POSIX-like environment, this comes by no surprize. |
|
It worked on Cygwin for a long time, then suddenly stopped working when I updated Git. I don't think this is Cygwin-specific. I got around it by creating a mount, as someone suggested. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setup
Windows 7 64-bit.
defaults?
to the issue you're seeing?
Remote repository is a shared folder.
Details
Git Bash.
Minimal, Complete, and Verifiable example
this will help us understand the issue.
Successful push like in Git 2.10.2.
Push failed:
But Git understands the URL:
URL to that repository to help us with testing?
You should be able to reproduce it with any repository. The only requirement is that the remote repository should not have objects (commits) you're going to push.
The text was updated successfully, but these errors were encountered: