From mboxrd@z Thu Jan 1 00:00:00 1970 From: cgit at cryptocrack.de (Lukas Fleischer) Date: Wed, 14 Aug 2013 10:56:36 +0200 Subject: RFE: download patch between arbitrary revisions In-Reply-To: References: <51ABEF0F.3030909@kernel.org> <20130603184953.GK1072@serenity.lan> <20130613215810.GB29281@blizzard> <20130613222126.GC23890@serenity.lan> <20130616075655.GA27832@blizzard> <20130616101122.GA4676@serenity.lan> <20130616191818.GA13580@blizzard> <52014D31.1060907@kernel.org> <20130806214035.GA30240@blizzard> Message-ID: <20130814085636.GA22320@blizzard> On Mon, Aug 12, 2013 at 01:05:18PM -0600, Jason A. Donenfeld wrote: > This is a wonderful idea. > > The sequence of patches provides a somewhat ridiculous way of > reassembling a git repository from cgit without using the proper http > clone endpoints; I wonder how long it will be before somebody winds up > (ab)using this for this purpose. A max-patches-per-request could > really help to prevent the DoS. On the otherhand, aren't there are a > few other endpoints that can cause similar DoS? If so, maybe we ought > to save max-patches-per-request for another commit that handles other > DoS cases too, and perhaps if we're lucky then be able to consolidate > them into one configuration setting at that point -- > max-operations-per-request. > > Anyway, go ahead and implement it -- > > * /patch/ will support id2 param and return format-patch --stdout id1..id2 > * /diff/ will be unchanged > * /diff/?raw=1 will spit out the raw output I implemented it as /rawdiff/ for now since /diff/?raw=1 turned out to be a bit more involved to implement. Up to now, the decision on whether to include the HTML layout (including the header, navigation bar) or not is solely based on the command ("patch", "diff", ...) that is used. I can try to change this if you feel strongly about it. > > Sound good?