From mboxrd@z Thu Jan 1 00:00:00 1970 From: mricon at kernel.org (Konstantin Ryabitsev) Date: Tue, 06 Aug 2013 15:23:29 -0400 Subject: RFE: download patch between arbitrary revisions In-Reply-To: <20130616191818.GA13580@blizzard> 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> Message-ID: <52014D31.1060907@kernel.org> On 16/06/13 03:18 PM, Lukas Fleischer wrote: >>>>>>> There is currently a way to render a diff between two arbitrary objects, >>>>>>> e.g.: >>>>>>> >>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=v3.10-rc4&id2=v3.10-rc3 >>>>>>> >>>>>>> However, there doesn't appear to be a way to download a patch in the >>>>>>> same way -- it will only make patch against id's parent. E.g.: >>>>>>> >>>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=v3.10-rc4&id2=v3.10-rc3 >>>>>>> >>>>>>> Any way we can make the behaviour of patch match that of diff? >>>>>> >>>> [...] >>>> >>>> So: >>>> >>>> /patch/?id=v1.8.3.1&id2=v1.8.3 >>>> >>>> generates something like "git format-patch v1.8.3..v1.8.3.1". And >>>> >>>> /rawdiff/?id=v1.8.3.1&id2=v1.8.3 >>>> >>>> generates the diff with no HTML around it. >>>> >>>> The latter could be a query parameter instead ("raw=1"?). Having not >>>> investigated the impact on the code, I have no preference for one over >>>> the other. >>> >>> Sounds good to me either way. Jason? >>> >>> Also, I just wondered whether this could be used to DoS servers when >>> requesting a series of patches for a huge range of revisions... Maybe >>> there should be some kind of limit? >> >> The "diff" version costs about the same regardless of how many revisions >> are between the endpoints - it's purely a function of the size of the >> tree (and the number of changed files which probably is affected by how >> far apart the commits are, but it's still bounded by the size of the >> tree). >> >> I can see it potentially being a problem in the "format-patch" case, so >> perhaps we want to add a "max-patches-per-request" variable if we do >> implement that. > > Yeah, the `git format-patch` case is what I meant with "requesting a > series of patches". Limiting the number of patches also sounds good to > me. > > I will go ahead and implement this if Jason likes the idea :) Hi, all: We keep getting requests for this feature, so I'm going to bump this in hopes that this gets implemented in the next release. :) Best, -- Konstantin Ryabitsev Senior Systems Administrator Linux Foundation Collab Projects Montr?al, Qu?bec -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 730 bytes Desc: OpenPGP digital signature URL: