From mboxrd@z Thu Jan  1 00:00:00 1970
From: cgit at cryptocrack.de (Lukas Fleischer)
Date: Tue, 6 Aug 2013 23:40:35 +0200
Subject: RFE: download patch between arbitrary revisions
In-Reply-To: <52014D31.1060907@kernel.org>
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>
Message-ID: <20130806214035.GA30240@blizzard>

On Tue, Aug 06, 2013 at 03:23:29PM -0400, Konstantin Ryabitsev wrote:
> 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. :)

Yeah, I already started writing a patch -- just waiting for Jason's
approval since it might take some time to polish it and make it ready
for submission.

> 
> Best,
> -- 
> Konstantin Ryabitsev
> Senior Systems Administrator
> Linux Foundation Collab Projects
> Montr?al, Qu?bec
>