Re: wishlist; unify behavior while cloning non-bare repos over http to be in line with ssh/local

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 10 May 2016, Jacob Keller wrote:
> > 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.

On Tue, 10 May 2016, Junio C Hamano wrote:

> >> 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.

Sure -- workarounds are possible, and we are at the state that many dependent
projects seems are doing that already (as above noted Jenkin's Git plugin, smth
along the lines probably done by github for https as well).  In my case I even
have managed to erect a lovely apache rewrite rule which seems to work, so I
can just 'git clone --recursive' a collection of 30 submodules without a hiccup
(we are also interested in .git/annex part here ;) ).  Citing here if it
comes handy for anyone

    # To overcome http://thread.gmane.org/gmane.comp.version-control.git/293777
    # we need to rewrite urls so that there is no need for explicit .git/
    RewriteEngine On
    RewriteCond "!.*/\.git/.*"
    RewriteRule "(.*?/)((?<!\.git/)(HEAD|config|annex/objects/.*|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}.(pack|idx))|git-(upload|receive)-pack)|info/refs)$" "$1.git/$2" [PT]

and sure thing in our project now we can add such sensing for .git/ and/or
reattempts to request again.  But that is the point -- it seems to be a
relatively common hiccup which could be fixed in the "root".  So I (and
possibly others) would just very much appreciate if it was (thus it was a
[wishlist] ;) )

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]