On Tue, May 10, 2016 at 1:11 PM, Junio C Hamano <gits...@pobox.com> wrote: > Yaroslav Halchenko <y...@onerussian.com> writes: > >> On Fri, 06 May 2016, Yaroslav Halchenko wrote: >> >>> Dear Git Folks, >> >>> Originally this issue was mentioned in previous thread [1], and I have >>> decided >>> to bring it into a separate thread. ATM there is a dichotomy in git >>> behavior >>> between cloning non-bare repos: if I clone over ssh or just locally by >>> providing url without trailing /.git, git senses for /.git and works just >>> fine >>> with ssh or local repositories, but fails for "dummy" http ones, the demo >>> script is here [2] which produces output listed below. From which you can >>> see >>> that cloning using http URL to the repository without /.git fails (git >>> version >>> 2.8.1, Debian). As it was noted in [1], concern could have been to not >>> traverse website since could lead to dangerous places. But .git is under >>> originating url directory, as well as info/ or HEAD or any other object >>> accessed by git, so IMHO this concern is not a concern. > > I am afraid that the reason why you saw no response is primarily > because nobody is interested in extending dumb commit-walker HTTP > transport after the world has largely moved on and abandoned it. > > The necessary update to the client might as simple as using > $GIVEN_URL/.git/ and attempting the request again after seeing the > probe for $GIVEN_URL/info/refs fails. > --
I know at least Jenkin's Git plugin has a workaround to solve this issue that is quite similar. Thanks, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
