From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Mon, 14 Mar 2016 22:44:50 +0000 Subject: odd patch issue In-Reply-To: <20160314154431.62d9f5d7@sheelba.scrye.com> References: <20160314134629.63b858f5@sheelba.scrye.com> <20160314212037.GA20327@serenity.lan> <20160314154431.62d9f5d7@sheelba.scrye.com> Message-ID: <20160314224450.GB20327@serenity.lan> On Mon, Mar 14, 2016 at 03:44:31PM -0600, Kevin Fenzi wrote: > On Mon, 14 Mar 2016 21:20:37 +0000 > John Keeping wrote: > > > On Mon, Mar 14, 2016 at 01:46:29PM -0600, Kevin Fenzi wrote: > > > We are seeing an odd behavior with diffs/patches here. I think it's > > > a bug, but perhaps we are doing something wrong. ;) > > > > > > If you look at: > > > > > > https://fedorapeople.org/cgit/adelton/public_git/CGI-sessions.git/diff/app.cgi?id=additional-attributes > > > > > > you can see just the diff for that one file. > > > However, if you try and get a patch for just that one file: > > > > > > https://fedorapeople.org/cgit/adelton/public_git/CGI-sessions.git/patch/app.cgi?id=additional-attributes > > > > > > You get also any other files affected in that patch. (ie, not just > > > app.cgi). Is this expected? or a bug? > > > > I think this is expected. It doesn't really make sense for "patch" to > > use a path since it includes the header and commit message, so it > > doesn't take a path argument. (Hopefully you created that URL > > manually and didn't follow a link - if we generate such a link that > > is a bug.) > > The downstream reporter claims that this worked as they want in the > past. ;( > > https://fedorahosted.org/fedora-infrastructure/ticket/4811 Indeed it did, so I think we should do this: -- >8 -- Subject: [PATCH] patch: reapply path limit This was originally applied added in commit eac1b67 (ui-patch: Apply path limit to generated patch, 2010-06-10) but the ability to limit patches to particular paths was lost in commit 455b598 (ui-patch.c: Use log_tree_commit() to generate diffs, 2013-08-20). The new output is slightly different from the original because Git's diff infrastructure doesn't give us a way to insert an annotation immediately after the "---" separator, so the commit has moved below the diff stat. Signed-off-by: John Keeping --- ui-patch.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/ui-patch.c b/ui-patch.c index 4c051e8..e8b5338 100644 --- a/ui-patch.c +++ b/ui-patch.c @@ -18,9 +18,13 @@ void cgit_print_patch(const char *new_rev, const char *old_rev, struct commit *commit; unsigned char new_rev_sha1[20], old_rev_sha1[20]; char rev_range[2 * 40 + 3]; - char *rev_argv[] = { NULL, "--reverse", "--format=email", rev_range }; + const char *rev_argv[] = { NULL, "--reverse", "--format=email", rev_range, "--", prefix }; + int rev_argc = ARRAY_SIZE(rev_argv); char *patchname; + if (!prefix) + rev_argc--; + if (!new_rev) new_rev = ctx.qry.head; @@ -79,7 +83,9 @@ void cgit_print_patch(const char *new_rev, const char *old_rev, rev.max_parents = 1; rev.diffopt.output_format |= DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH | DIFF_FORMAT_SUMMARY; - setup_revisions(ARRAY_SIZE(rev_argv), (const char **)rev_argv, &rev, + if (prefix) + rev.diffopt.stat_sep = fmt("(limited to '%s')\n\n", prefix); + setup_revisions(ARRAY_SIZE(rev_argv), rev_argv, &rev, NULL); prepare_revision_walk(&rev); -- 2.8.0.rc1.128.gf7e6a6c